RE: [dss] some changes in requirements draft 3

[Trevor Perrin <trevp@trevp.net>]

At 02:13 PM 4/11/2003 -0400, jmessing wrote:


> >>Third, using SAML may make some sense where a relying party upon the
> >>signature has already agreed to trust the SAML assertions of a particular
> >>domain, but not necessarily otherwise.
> >
> >I don't understand.  The relying party has to trust the DSS Service to
> >speak authoritatively about the sender's identity and authentication no
> >matter what, what format we encode this in is an orthogonal issue.
> >
>
>Contrary to this assumption, a relying party does not have to trust any 
>one or any thing it is not comfortable trusting. Suppose A wants to borrow 
>money from D. A promises to repay the money with interest. D will insist 
>on the promise being enforceable before D will part with the money. A's 
>signature is a way to accomplish the goal, if the signature is legally 
>enforceable, which depends in large part, but not exclusively, on whether 
>A is really A. Unless D is assured within the limits of D's comfort level 
>of both of these points (enforceability and identity), the transaction 
>will not be accomplished.
>
>If A tenders to D a note that is signed by C, a DSS allegedly acting on 
>behalf of A,  and incorporates a SAML assertion that C identified A on the 
>basis and within the validity period of a SAML assertion by B about A's 
>identity, D may well respond "so what?" unless at the very least, D is 
>also willing to trust B's authentication assertion. Otherwise, the SAML 
>assertion is superfluous. From D's point of view, it is equivalent to 
>saying that the man in the moon vouches for A's identity.
>
>The SAML assertion in this case means little to D's concern that it may 
>never get repaid.

Suppose D doesn't know anything about B - are you saying that D will reject 
the signed note for this reason, or will D say "well, I've never heard of 
B, but since C trusts his Assertion, I will too".

I think the latter would be the better semantics - C could always just 
re-issue his own Assertion, but including B's Assertion instead is a way of 
giving more visibility into authentication details - the relying party may 
know something extra about B that he could make decisions on, or he may 
not, in which case he should just assume the Assertion is vouched for by C, 
even though B issued it.



>D should also want to know, even if it does trust B on the basis of a 
>digital identifier like, for example, a security token, what steps were 
>taken to assure that A was really A when the digital identifier was first 
>given to A or generated by A, and even afterwards in terms of maintenance 
>of the security of A's token. The first of these considerations is often 
>considered to be out of spec in the writing of standards, yet it is 
>critical to D's concerns.

The Liberty Alliance has extended saml:AuthenticationStatementType to a 
type that contains a richer description of authentication methods, to 
describe things like how the subject was initially identified, how his 
credential has been kept secure, and other stuff, and then to map these 
details to named classes for ease of reference.  I don't fully understand 
it, but it may be a way of representing the information you mention within 
SAML:
http://www.projectliberty.org/specs/
See 3.2.2.4 of "Protocols and Schema Specification", and see 
"Authentication Context Specification".


Trevor