RE: [dss] Comments on Core WD 01 3 Oct 03

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

OK on (4).

On 8 - I was referring to the structure agreed in the requirements document.

I do not believe that TLS includes a protocol element for carrying
authentication tokens.

I also think that the best place to put single sign on tokens is with the
DSS application, not the protocol that carries the peer to peer exchange.

Nick

>
> > > >8) 3.4.4 Claimed Identity
> > > >
> > > >This should to structured as proposed in the dss
> requirements document
> > > >(3.2.2).
> > > >
> > > >·       Requestor Name (in a type/value format such as a SAML
> > > NameIdentifier)
> > > >·       (Optionally) Information supporting the name (such as a SAML
> > > >Assertion,
> > > >Liberty Alliance Authentication Context, or X.509 Certificate)
> > >
> > > That's for *Requestor Identity*, not necessarily claimed
> identity.  The
> > > information supporting the name (certificate, assertion,
> etc.), should be
> > > delivered by the underlying binding, I think.  So can we get by
> > > with just a
> > > string here?
> > >
> >Using the underlying binding is just one way of providing the
> >authentication.
>
> I thought it was the only way we wanted to support.
>
>
> >    For single sign on / liberty / SAML type of authentication
> >there can be a form of token which is used to support the name.
>
> Yes, but it would be transferred through the underlying binding,
> right?  I.e., if the client is authenticating with WS-Security,
> or TLS, or
> whatever, these underlying protocols will handle transmission of certs /
> assertions / tokens / etc.?
>
>
> >Also, a type identifier for the name would be useful (see SAML
> >NameIdentifier structure).
>
> That makes sense.
>
>
> >I request that we include the previously agreed structure.
>
> I'm not sure which structure you're referring to.
>
> Trevor
>
>
>