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

[Trevor Perrin <trevp@trevp.net>]

At 09:47 PM 10/13/2003 +0100, Nick Pope wrote:


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

Suppose a client wants to add an enveloped signature to this document:

<someDocument ID="doc1">
   ...
</someDocument>

The signature will refer to the document through a same-document reference 
"#doc1".   Currently, the document is stored at the URI 
http://acme.com/document.xml.  So the client would send:

<DocumentURI RefURI="#doc1">
   <URI>http://acme.com/document.xml</URI>
</DocumentURI>

The server uses <URI> to retrieve the document, and uses RefURI to 
construct a <ds:Reference> for the document.





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