[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] some changes in requirements draft 3
I also would object to having to support SAML just to obtain information on the type of name used. I agree that this would be useful in the cases where the assertion comes from a separate authority, but the DSS is just identifying the requestor, rather than making a general assertion, this is an overkill and implies a different semanitics a general SAML assertion. Nick > -----Original Message----- > From: Anthony Nadalin [mailto:drsecure@us.ibm.com] > Sent: 10 April 2003 04:45 > To: dss@lists.oasis-open.org > Subject: RE: [dss] some changes in requirements draft 3 > > > > > > > Why is this limited to SAML as SAML is not the only assertions we have to > deal with, this needs to be generalized > > Anthony Nadalin | work 512.436.9568 | cell 512.289.4122 > > > |---------+----------------------------> > | | Trevor Perrin | > | | <trevp@trevp.net>| > | | | > | | 04/09/2003 04:02 | > | | PM | > |---------+----------------------------> > > >----------------------------------------------------------------- > ------------------------------------------------------------------ > -----------| > | > > | > | To: Nick Pope <pope@secstan.com>, > dss@lists.oasis-open.org > | > | cc: > > | > | Subject: RE: [dss] some changes in requirements draft > 3 > | > > >----------------------------------------------------------------- > ------------------------------------------------------------------ > -----------| > > > > > At 09:49 AM 4/9/2003 +0100, Nick Pope wrote: > > >Trevor, > > > >The reason is that it is a separate assertion, with its implied > semantics, > >but part of the DSS information. > > If we used a full Assertion then the relying party could process it with a > SAML toolkit. Also, in cases where the DSS service was authenticating the > requestor based on a SAML Assertion, it would be easy just to embed that > Assertion in the signature. > > Also, a full Assertion contains some fields that would be useful. > Within the top-level <Assertion>: > - <Issuer> to identify the Authentication Authority who > authenticated the > > Requestor (which may not be the DSS service) > - <AssertionID> to identify the authentication instance for > auditing/dispute resolution > Within an <AuthenticationStatement>: > - <AuthenticationInstant> to identify when the authentication took place > - <SubjectConfirmation> specifies data (such as a public key) that the > relying party can use to authenticate the requestor > - <AuthorityBinding> specifies a service where more information > about the > > subject can be queried from > > So all this could give the relying party visibility into not just who the > requestor is, but how he was authenticated. So I'd say just use a full > SAML Assertion with an <AuthenticationStatement> (SAML was designed as a > general framework, within which other types of "statements" could > be made). > > > Trevor > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]