Subject: [dix] SAMLv2-LowLow: Bindings and Profiles?

From: Nick Ragouzis <[email-masked]>
Date: Mon, 20 Feb 2006 17:45:52 -0800

[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-masked]> @ 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-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 20 Feb 2006 18:17:48 -0800

> just name=value pairs, instead of those nasty scary pointy

I note that JSON has been submitted as an Internet-Draft: <https:// 
datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=14139>

Lisa