RE: [dss] some changes in requirements draft 3

["Nick Pope" <pope@secstan.com>]

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
>
>
>
>
>