[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)
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]