RE: [dss] Requester Identity (was RE: [dss] requirements draft 4)

["Nick Pope" <pope@secstan.com>]

Trevor,

I see your point.  I remain neutral at the moment the about what can go in
the "supporting infromation" other than I think that it should be there for
extensability.

I do think, as in my last point, that there should be the ability to
indicate how the user identity was checked - passsword, kerberos, X509 etc.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 04 May 2003 22:55
> To: Nick Pope; Robert Zuccherato; dss@lists.oasis-open.org
> Subject: RE: [dss] Requester Identity (was RE: [dss] requirements draft
> 4)
>
>
> At 10:01 PM 5/4/2003 +0100, Nick Pope wrote:
> >Content-Transfer-Encoding: 7bit
> >
> >Robert, Trevor and all
> >
> >I broadly agree with what you propose.  May I suggest some
> simplifications.
> >
> >Since the SAML NameIdentifier without any of the optional attributes is a
> >string the first requirement for a Simple Name string can be met
> by the SAML
> >NameIdentifier structure.
> >
> >I am not cear what is being proposed by RFC 3280 GeneralName.  I
> assume that
> >this doesn't mean the ASN.1 encoded structure but the ability to
> include all
> >the name forms in GeneralName.  Many of these are already
> included as name
> >type in SAML NameIdentifier including X509SubjectName, emailAddress.
> >
> >Thus I propose that text is updated as follows:
> >
> >"..... This will include:
> >1) The name of the requestor as a simple name string or specific
> name forms
> >such as X509 subject names, email addresses, IP Address, email
> address, DNS
> >Name, EDI party name, URI, directory name.
> >
> >Note: The SAML NameIdentifier syntax can be used to encode this
> information.
> >
> >2) Information provided to confirm the name of the requestor
> such as a SAML
> >Assertion, WSS Token, Kerberos Token ...."
> >
> >In addition, I propose that the DSS service may identify the
> means used to
> >confirm the name rather than carrying the token used to authenticate the
> >user.
>
> I like this 2-part division into a simple name syntax, and an
> optional/extensible element for giving more details.
>
> About putting the token the user authenticated with into the 2nd element:
> if it's a Kerberos ticket, won't it be encrypted to the DSS service, and
> thus unreadable by anyone else?  If it's a WSS UsernameToken,
> then doesn't
> it refer to a username/password shared by the user and the DSS, and thus
> not probably not known to anyone else? (if I'm wrong on these points,
> please correct me).
>
> An X.509 cert would make sense in this context, though.  It seems
> that the
> SAML <Advice> element might be designed to carry this sort of "evidence
> supporting the assertion claims".  Do any of our SAML experts
> know if it's
> intended for this?  (or should we ask SAML about it?).
>
> Trevor
>
>
>