[Thread note:
To avoid expanding this email, and follow on digests, I've broken
the prior email up into several different threads. As we don't have
real distinguishing topical thread names, yet ... so I didn't see
that as a problem. Apologies in advance if it's bothersome.
The original thread continues on:
1. Setting aside irrelevant or incomplete histories
2. Meaning of Simple? Basis for concrete and specific requirements.
3. SAMLv2-LowLow: Bindings and Profiles?.
]
Dick,
Dick Hardt <[EMAIL PROTECTED]> @ Tue, 14 Feb 2006 02:17:22 -0800 wrote:
<snip>
> SAML immediately implies an XML document. That is heavier then
> name/value pairs.
>On 25-Jan-06, at 11:03 AM, Nick Ragouzis wrote:
> >
> > 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
Yep, it's true that SAML is defined wrt an XML encoding for security
assertions. So, yes, that's what SAMLv2 uses today, in its initial
form.
But, I'm not so sure that "SAML immediately implies an XML document,"
since, e.g., SAML includes aspects regarding HTTP cookies, and HTML
form-encoded content. Beyond that, and more importantly, there are
other crucial facets to SAMLv2:
1. SAML's built in extensibility and composability, so arguably
it could be carried in any format; and,
2. SAML is more than the wire exchanges. I think that one could
say that SAML is actually more about:
a. The responsibilities of the entities who participate
as SAML Requesters and Responders; and,
b. The ability to bridge several regimes and domains,
including: classes of authentication and the tokens
and devices inherent therein; communication among and
between attribute domains and authorities, even those
using different mappings; the proxying and linking of
different domains of authority; bridging between
different domains, including X.509v3, LDAP, and Windows
All of which makes it certainly more than about using XML to
exchange assertions. But it's pretty good at that, so far.
Let's continue the thinking with that SAMLv2-LowLow, assuming
we've decided to create a minimized profile of SAMLv2, using
its extensibility and composability features.
We know the SSO HTTPPOST profile is entirely REST, so we can
build from there.
What we're thinking next is: what we'd like is a binding that is
just name=value pairs, instead of those nasty scary pointy
brackets.
So let's do just that, say: SAML:2.0:bindings:HTTP-CGI
Using this binding, any requester or responder could (create and
canonicalize and) send those SAML-LowLow elements and attributes
according to our defined serialization and encoding schemes.
To complement this we'd like a profile where this binding would
be used. Just quickly I'd guess we couldn't just add binding-
specific processing rules to SAML's WebSSO HTTP POST profile,
but we'd instead define a new profile: SAML:2.0:profiles:SSO:dix.
Using this profile (which requires the HTTP-CGI binding) a SAMLv2
relying party (including Membersite) could use name-value pairs to
talk to a SAML-LowLow supporting SAML IDP for authentication, and
so on.
- - - -
Now, why do any of this? Especially when we could just plunk some
hidden elements on a form?
Well, first off, although we might be able to bend SAML to our
purposes -- it's still a question whether we'd want to do that.
The exercise is meant, more, to encourage us to not hold loosely-
defined ideas as design criteria for a security protocol. I for one
am looking for a specific statement of gaps, and a succinct
statement of objectively-testable concrete goals. I think the
threshold is higher than for something new in a new field.
Second, as I discussed in another email, the Homesite isn't just
some site that can process requests. The processing of even dmd00
holds intrinsic responsibilities and burdens on operations and
security and privacy, among others. This is an important factor
to any significant deployment of something like dmd00.
The immediate implication is that processing from a SSO:dix
Membersite to a SAMLv2 LowLow-IDP would offer that Membersite a
significant trust authority.
Third, this promises users and their Membersite-like relying parties
a user-controlled gateway to a broad range of attributes and
capabilities -- just the kind of things that we might want to
pop up on our blogs, etc (geolocation, direct publication and
community updating of media preferences, cross-family activities,
etc.)
Fourth, beyond simple attributes, this would provide the kind of
interoperability that real end users and service providers,
together, might appreciate. Use cases would include all the
typical cross-overs, from corporate/school/medical/banking/media/
national/state to personal/entertainment/recreation/hobbies/writing
and do that while assuring privacy, security, and independence
across providers of all levels.
Fifth, perhaps also because some of us would prefer to not be paying
yet more license fees and device leases on more protocol gateways
and bridges, with even more maintenance sync points, and points of
failure. :-)
Best,
--Nick
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
