Subject: [abfab] SAML draft and naming issues

From: "Jim Schaad" <[email-masked]>
Date: Thu, 1 Nov 2012 17:55:48 -0700

I really don't like the fact that the current draft says that the subject
field is omitted when constructing a request.

1.  It means that I cannot use my existing validating parser for this as we
will no longer have schema compliant XML for the request.
2.  See #1
3.  I believe that one will need/want to ask questions about multiple
entities involved.  That is one might want to ask about both the user and
the user's machine.

I would propose making the following changes

1.  Define a new name type that has two string values "user" and "machine".
This corresponds to the current set of identity types that is defined by
TEAP.  This would also allow for anonymous names to be returned to the RP
without any problems

2.  Either define or reference a SAML name type for NAIs.  I am not sure if
the new and old NAIs should be done differently as there are some
differences between the name matching rules.  I also understand that if a
proxy re-writes the identifier in the RADIUS string, this field may not be
re-written as well depending on if the proxy is going to look for it.

I have a small concern about pseudonymous names, at present the first time a
client might see it's pseudonymous  name would be when it is transmitted
from the acceptor to the initiator as part of the application protocol.
There is currently no provision for an IdP to send the name to the client as
part of the current GSS-EAP protocol, and it is not clear to me that the
client should be required to contact the IdP prior to talking to the server
to setup for an anonymous name.

Jim

---

From: Josh Howlett <[email-masked]>
Date: Fri, 2 Nov 2012 14:19:18 +0000

Jim,

>will no longer have schema compliant XML for the request.

This surprises me. The relevant bit of the schema is:

<element ref="saml:Subject" minOccurs="0"/>

What specifically is your parser saying?

(I'll address the rest of your email when I return from holiday).

Josh.

Janet is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 2 Nov 2012 08:14:43 -0700

Josh,

I see it as 

<element name="SubjectQuery" type="samlp:SubjectQueryAbstractType"/>
<complexType name="SubjectQueryAbstractType" abstract="true">
<complexContent>
<extension base="samlp:RequestAbstractType">
<sequence>
<element ref="saml:Subject"/>
</sequence>
</extension>
</complexContent>
</complexType>

Which does not have an optional on the subject

Jim

> -----Original Message-----
> From: Josh Howlett [mailto:[email-masked]]
> Sent: Friday, November 02, 2012 7:19 AM
> To: Jim Schaad; [email-masked]
> Subject: Re: [abfab] SAML draft and naming issues
> 
> Jim,
> 
> >I really don't like the fact that the current draft says that the
> >subject field is omitted when constructing a request.
> >1.  It means that I cannot use my existing validating parser for this
> >as we will no longer have schema compliant XML for the request.
> >2.  See #1
> 
> Janet is a trading name of The JNT Association, a company limited by
> guarantee which is registered in England under No. 2881024 and whose
> Registered Office is at Lumen House, Library Avenue, Harwell Oxford,
Didcot,
> Oxfordshire. OX11 0SG

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 2 Nov 2012 15:24:18 +0000

><element name="SubjectQuery" type="samlp:SubjectQueryAbstractType"/>

I was going to ask if this was limited to AuthnRequests or included
queries. If the latter, then yes, it's required.

Note that this isn't a question of "nice to be valid". The schema is not a
parsing tool in the spec, it's the normative description of the grammar of
the standard. Validating the XML is optional, but conforming to the schema
is not.

However, Subject contains different options for representing identity, and
there are ways to express "derive identity from context" if that's what
you're after.

-- Scott

---

From: Josh Howlett <[email-masked]>
Date: Mon, 5 Nov 2012 16:50:38 +0000

>TEAP.  This would also allow for anonymous names to be returned to the RP

I see no problem with this in principle, but there's probably a discussion
needed on a couple of points:

1. Should these get defined by Abfab, or in the place(s) where these
attributes are actually going to be used? If this is a generic
requirement, it should probably happen in Abfab. Conversely if you are
trying to solve a specific problem (e.g., for Plasma) it might be better
defined there.

2. Are these best defined as name identifiers or attributes? The answer to
this probably boils down to the specifics of the use case(s). Do you have
these described anywhere?

(I'm not throwing these discussion points up to avoid work; from
experience, defining attributes can be a slippery slope into
ocean-boiling).

In any case, I'll take a look at the TEAP identity types and propose some
straw-man text.

>re-written as well depending on if the proxy is going to look for it.

No problem with this in principle, but again it would be helpful to
determine if this is a sufficiently generic requirement that it makes
sense to define within Abfab or, if application-specific, elsewhere.

> I need to do multiple queries [...] I cannot serialize them, as I would
> with the HTTP binding  How do I deal with it here?

Why do you think that you cannot serialize them?

> Profiling of the different attribute query based on the content - looking
> at the SAML Profile document and the namespace of the attributes that
> can be used in a single query

Sorry, I am having difficulty parsing this. Could you explain again?

Thanks, Josh.

---

From: Josh Howlett <[email-masked]>
Date: Thu, 8 Nov 2012 15:53:51 +0000

>queries. If the latter, then yes, it's required.

It is limited to AuthnRequests.

(There is an Abfab profile that deals with queries; but this merely
describes how to use the SAML 2.0 Assertion Query/Request Profile using a
particular synchronous binding, RADIUS. The protocol semantics are
equivalent).

Josh.