Subject: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter - consensus?)

From: Nick Ragouzis <[email-masked]>
Date: Wed, 25 Jan 2006 11:03:33 -0800

Dick Hardt <[email-masked]> @ Wed, 25 Jan 2006 00:13:31 -0800 wrote:

> On 24-Jan-06, at 9:23 AM, Tom Doman wrote:
> 
> > Yes, Leslie, taking your thought further, it makes me wonder, how  
> > does the DIX protocol end up being much different from SAML?  Dick,  
...  
> > but I'd like to have you weigh in
... 
> > where 
...
> > SAML is lacking or perhaps inappropriate for digital identity 
> > information exchange?
> >

NR: I think this is an important question to answer with specifics,
    as best as one can in the moment, before we dedicate a lot of
    energy and resources -- if we're going for an improvement in
    some dimension(s), then it serves us to be clear about it.

> 
> Hey Tom
> 
> I think the SAML authors did a great job of standardizing a language  
> to represent assertions to be moved between systems, and was driven  
> by vendors wanting to enable interop with between their enterprise  
> solutions.  

NR: Um, was driven ^in part^ by such vendors. In this forum, in the 
    inclusive fashion marking this and other SDO, let's be straight 
    about this, or be silent. Self-interest has many guises.

[
> I think it is/was difficult from that point of reference  
> to think of how to move digital identity around at Internet 
> scale, or to scale down the required technological footprint for
]
...
> low risk, low value identity transactions. 

NR: Seems a reasonable use case. But not one exclusive of SAML, right?
    Possibly also the case, in the least, that relying parties might 
    be served by being able to easily distinguish among, and even have 
    granular mechanisms for selecting the 'level' of, the footprint 
    (and security). Which suggests certain mechanisms as valued in
    each of the protocols -- but which might not be strictly 
    necessary in any of them alone.

> Processing digitally signed XML is much harder then fetching 
> an HTML page and working with name/pairs. 

NR: This is a non-sequitor to your claim, below. If it's possible in
    some future for DIX to handle the 'SAML token', well then you're 
    suggesting inclusion of precisely this sort of thing within DIX
    (the processing digital sigs).

    And, OTOH, within the SAML (i.e., v2.0) WebSSO, the "fetching"
    (assuming from this para and by the below you mean the transport 
    part) can be precisely just dealing in straightforward REST.

[
> SAML is pretty heavy to move my name, email address and blog URL. 
> It also does not integrate well into existing applications. The ID 
> submitted allows an existing form to use DIX with the addition of HTML, 
]
...
> and no change to the existing form processing code (assuming the 
> required fields are available)

NR: Well, not quite. The minimal change is the required change: 
    to make the application aware of identity attestations of a 
    trusted third party. 

    So far I'm not convinced by your characterization, Dick.

    Let's take a "what if". 

    Let's create a SAMLv2.0 "SAML-LowLow" profile, a sort of reduction
    to SAMLv2.0 WebSSO HTTPPost, that removes any signature requirement 
    (even tho that's token, not necssrly transport), and assumes some 
    of the party/counterparty status that's assumed in the ID (leaving 
    any transport-related digest or dsig to the same discussion needed 
    in dix). 

    Here's a rough of the "heaviness" of such a speculative profile (of 
    which obvious parts can appear in htmlforms, and for which I've 
    ignored the trivial serialization into url form):

Request (by relying party): 
 @ID of the request
 @Version of the protocol 
 @IssueInstant of the request
 Issuer UID
 Subject identifier related to the request

Response (by authority):
 @ID of the resp
 @Version of the protocol
 @IssueInstant
 @InResponseTo the RequestID
 Status for request
 Assertion (unsigned in this SAML-LowLow profile):
   @ID of the assertion
   @Version of the protocol
   @IssueInstant
   Issuer UID
   Subject's ID
   Authentication Statement
     @AuthnInstant
     AuthnContext

NR: Right off this is indeed heavier. But what's the *objective* bar? 

    Some of the extras are probably unnecessary for the "low risk, low
    value" use case, sure. Unfortunately, or not, using SAMLv2 you
    can't really shed yourself of those attributes on the base
    request and response elements. But these particular 'extras' are 
    trivial capabilities inherent in any forms generation and 
    processing engine, right? 

    Beyond that this "SAML-LowLow" profile could even be lighter,
    if that’s what's required. Such as removing the Authentication
    statement ... although I'm at a loss for why that would save 
    significant resources when doing so would remove some valuable 
    *optional* capabilities for the requester.

    Of course a further simplified version of this could be had by
    profiling the Liberty ID-FF1.2 standard.

    And, more, this doesn't handle capability discovery. But that's
    not DIX's raison d'etre as of yet, right?

...
> 
> Summary: The token part of the SAML specs map to a type of 
> thing that can be moved around DIX, the protocol part is missing 
> chunks 

NR: I didn't deal with this, but it would be good to be
    more specific here.

> and is not light enough.
> -- Dick

--Nick

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix