RE: [dss] some changes in requirements draft 3

[Anthony Nadalin <drsecure@us.ibm.com>]

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