[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Comments on draft 0.7a S2ML specification
I'd like to offer a few comments on the v0.7a S2ML document. Generally, I think that it embodies many good goals and useful ideas, but believe that some aspects may be in need of refinement or further specification. The goals of independence from particular authentication and authorization schemes are good. The notion of using a PK-based signing authority to sign a name assertion, vouching for an identity which may have been authenticated by a variety of authentication systems, is a good unifying principle. The idea of providing means to represent authorization queries and return results in response to those queries is a valuable and important function, though one which has historically been difficult to standardize. Extensibility in this area (as is provided, e.g., for the entitlement contents) seems particularly important. I'm wondering about a couple of aspects related to authentication requests. Page 15 specifically places challenge-response protocols outside scope for v1.0. Nonetheless, it seems likely that support for iterated, multi-step user authentication transactions will be needed at some point; it may make sense to anticipate this need with some form of continuation hook in the request and response messages which carry authentication transactions. For AuthRequests with PKI Credentials, it's clear how a public key or name can be identified, but some other element (either in Credentials or external to it) may need to be defined with which a requestor can demonstrate that it possesses the corresponding private key, thereby accomplishing the verifiable authentication. Functionally, the cryptographic construction discussed in Sec. 6.1 for the HTTP binding seeks to bind a sender ID (URI) to an assertion object reference, in a manner that is transferable among a set of sites sharing a common AES key. Linking the assertion via a URI (rather than cryptographically to a message stream, or to a key held by the entity authenticated by the name assertion) could leave the overall scheme subject to IP- (or DNS-) level spoofing, depending on how the URIs are constructed. The S/MIME binding in Sec. 6.2, in contrast, appears to apply a signed binding between the assertion, entitlements, and an actual document, an approach which would avoid this risk. I'd be interested to understand the rationale for this apparent divergence between the bindings for the different communications environments. --John Linn, RSA Laboratories
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC