OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Trevor,

Just a couple of follow up points.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 13 October 2003 00:01
> To: Nick Pope; OASIS DSS TC
> Subject: Re: [dss] Comments on Core WD 01 3 Oct 03
>
>
> At 10:09 PM 10/12/2003 +0100, Nick Pope wrote:
> >Content-Transfer-Encoding: 8bit
> >
> >I propose the following comments on the Core protocol and
> elements document:
> >
> >Nick
> >
> >Comments on DSS Core
> >
> >WD 01 3 Oct 03
> >



> >4) 2.2.3
> >
> >The input document has two URIs (URI as an element, and RegURI as an
> >attribute).  What is the relative role of these two URIs?  What
> if they are
> >different?
>
> RefURI tells the server what to put in the corresponding
> ds:Reference's URI
> attribute.  The <URI> element tells the server where to retrieve the
> document.
>
> RefURI gives the relative position of document wrt signature -
> for example,
> RefURI may be a same-document reference like "#doc1", whereas
> <URI> is just
> used as a mechanism to transfer the document from client to server.
>

I understand this from the protocol mechanism viewpoint.  However, I still
question the need for both parameters and why they could be different?



> >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.   For single sign on / liberty / SAML type of authentication
there can be a form of token which is used to support the name.

Also, a type identifier for the name would be useful (see SAML
NameIdentifier structure).

I request that we include the previously agreed structure.

Nick




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]