Re: [dss] Authentication requirement and having separatebindings/profiles

[Trevor Perrin <trevp@trevp.net>]

At 01:51 PM 3/5/2003 -0800, Trevor Perrin wrote:
>Content-Transfer-Encoding: 7BIT
>
>
>A while back, Robert suggested a requirement about authentication -
>http://lists.oasis-open.org/archives/dss/200301/msg00032.html
>
>Where do we stand on that?  What about doing like SAML, and having a 
>"Core" protocol spec which needs "Bindings and Profiles" to nail down 
>bindings details for the core protocol (such as transport, security, and 
>authentication); and to nail down profile details for how the signatures 
>that the core protocol produces are incorporated into application protocols.
>
>For example, a binding for using DSS to produce signed emails might use 
>HTTP or BEEP as a transport, and TLS and SASL for security.  A binding for 
>using DSS to protect XML documents might use SOAP as a transport, and 
>WS-Security and/or SAML for security.


To carry the analogy with SAML a little further: SAML has a core 
"Assertions and Protocols" document, and then a "Bindings and Profiles" 
document.

Like DSS, SAML is sort of a 4-corner model where a protocol between a 
client and server produces some datum (an Assertion in SAML, a Signature in 
DSS), and this datum can then be used with other application protocols.

So after the core protocol and datum are specified, then "bindings" are 
needed to instantiate the protocol in particular settings, and "profiles" 
are needed to specify how the datum is used in application protocols.

This suggests 2 things for us -
  - First, it may be good to have a separation between the core protocol, 
and its particular bindings.
  - Second, while, unlike SAML assertions, our "datum" (signatures) already 
exist, we may need to "profile" them, or get the groups responsible for 
these signature formats to profile them, to satisfy our use cases.

Particularly, the Identified Requestor use case mentions that the DSS "may 
sign all data with its own private key and simply include the name or 
identifier of the requester(s) within the scope of the data that is 
signed".  Current signature formats would need a Signed Attribute defined 
for them to support the inclusion of the requester's name.

Similarly, the e-filer application given as an example of the Court Filings 
use case is a server-based web app, that signs an uploaded document with 
its own key, then forwards the document on, so while it wouldn't use the 
DSS protocol, it might produce a signature with the requester's name 
embedded in it like mentioned above - thus this use case would benefit from 
work we did to profile 3rd-party-applied signatures, but not use our 
particular protocol.

Another example might be mandating that ds:Manifests must be validated 
(i.e. requirement 2.3.1), for the "Securing the transform chain" use case, 
and because that might make the "Client Side Hashing" use case easier.

Anyways, I made a similar point below - basically, I just think we should 
keep in mind that what we want may involve more than just a protocol that 
produces signatures, but some additions/profiling of these signatures 
themselves..
http://lists.oasis-open.org/archives/dss/200302/msg00019.html

Trevor 


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>