Sorry for the late response Nick, I had a flood of email a while ago
and am now just catching up ...
On 25-Jan-06, at 11:03 AM, Nick Ragouzis wrote:
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.
Agreed.
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.
Not sure what your point is here, sorry.
[
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.
SAML immediately implies an XML document. That is heavier then name/
value pairs.
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).
SAML tokens could be moved around by DIX. That does not mean all data
has to be in SAML tokens. Lots of low value transactions can be done
with name/value pairs, and no need for XML or XML-DSIG.
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.
only if you need that in your application. Lots of existing
applications just need name/value pairs. DIX could be added to such a
site without any code change, just additional HTML
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?
Really simple to implement. :)
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?
Are they though? Why don't form generators have them then?
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?
Well, that is part of the problem with SAML. It is not clear to an
average web developer how to get it all up and running.
Perhaps another way of looking at this is to ask the following
questions:
Why is SAML not widely adopted? Why is it not being used at Amazon,
Yahoo!, Google or MSN? It has been around long enough.
Why was SMTP standardized when X.400 was being worked on?
Why was LDAP created when X.500 was looming?
My opinion is because X.400 and X.500 were too heavy and did not
easily solve the problems people wanted to solve.
SAML solves some people's problems, but clearly is not solving a
bunch of other people's problems, or it would have been adopted by now.
-- Dick
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
