RE: [dss] some changes in requirements draft 3

[Trevor Perrin <trevp@trevp.net>]

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