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