OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]