Dick Hardt <[EMAIL PROTECTED]> @ 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 protected]
https://www1.ietf.org/mailman/listinfo/dix
