Subject: [dix] Meaning of Simple? Basis for concrete and specific requirements

From: Nick Ragouzis <[email-masked]>
Date: Mon, 20 Feb 2006 17:42:41 -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: 
> Sorry for the late response Nick, I had a flood of 
> email a while ago and am now just catching up ...

NP. It does serve to remind just how busy folks are in this 
community ... and why we'd want, as a community, to focus just 
on innovations of significant need and clear merit, and to build 
on what the community has achieved.

Dick continued:
> On 25-Jan-06, at 11:03 AM, Nick Ragouzis wrote:
> > 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.
> 
> Agreed.

Great.

In this dialog since Tom Doman's question (responding to Leslie's 
more general point about interoperability, etc; and to which Boris 
asked/suggested the same thing; to mention just a few) I don't 
think we've seen much that's specific or detailed on this. 

That is, about specific differences that could be either robustly 
described or objectively tested, as inappropriate or lacking (I don't 
think it has to be both.). We have these gaps proposed [PG], as far 
as I've noticed:

 PG1. Existing protocol SAMLv2 uses XML; we want non-XML;
      handling HTML and working with name-value pairs is
      about right 

 PG2. Existing protocol SAMLv2 is heavy; we want light.

 PG3. We don't want to use XML-DSIG.

Also, I think we've seen a few specifics floated about the 
surrounding environment that are also relevant to this question 
(proposed requirements, or proposed design criteria PDC?):

 PDC1. Easy for Perl, Python, PHP and Ruby developers in 
       addition to Java and .Net developers [was a core 
       goal of DIX, per D. Hardt 13Feb06]. (Tentative and 
       partial)

 PDC2. Do not require state management in the Membersite. 
       But we might want extensibility to allow benefits 
       for Membersites that can/do maintain state. 
       [characterization of current method in SXIP, per 
       D. Hardt 13Feb06] (Tentative and partial)

These are weakly related to the "Simple Deployment" requirement
proposed on the wiki.

Dick continued:
> > Dick Hardt continues: 
> >> 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.

Okay, so let's work from there. I've captured the XML bit in PG1, 
above. (And discussed a name/value serialization and encoding
for SAMLv2 in another email.)

I don't see an objection here to the other design criteria I 
floated (and which others have mentioned in various forms), so:

 PDC3. That Membersite would have ability to learn and/or require 
       a level of service from Homesite, regarding (e.g.,): 
       state-based services, Homesite security measures wrt and 
       form of: authentication of principal, timeliness of said
       authentication, assuring proper consent to data release, 
       etc., according to the value attached to the transaction 
       by the Membersite. (Tentative and partial, although dmd00 
       implies and otherwise specifies that it is a PG/G to 
       deliver parts of this. Questions are: which parts are
       separable? are these parts mutually complete? what
       mechanism is provided for specifying additional needs,
       e.g., through the fetch request msg parms?) 

 PDC4. Be open to additional requirements that enhance 
       interoperability (the presumption here is these would 
       otherwise not be 'naturally' a part of the base 
       conceptions and requirements). (Tentative and partial)

 PDC5. In pursuit of PDC4, be prepared to describe and communicate
       to SDO of other relevant standards changes which would
       improve interoperability with this protocol. For example,
       a profile of such a protocol. (Tentative and partial)

Before moving further let's roll-up the next item.

Dick continued:
> > Dick Hardt continues:
> >> 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.

Here's what I see there, but I could have it wrong: 
1. Low value differs from "no value" (otherwise we, and 
   Membersites, would not be concerned at all)
2. Processing digitally-signed XML is too hard. But there's
   a difference, right, between the burdens a Homesite vs.
   a Membersite are expected to shoulder?
3. Creating HTML pages, and handling HTTP POST with 
   name-value pairs is about right
4. DIX might "move around SAML tokens" ... but it would not
   be desirable for all data to have to be in "SAML tokens."

So, I have:

 PDC6. Membersites would be correct to expect Homesites to 
       maintain an higher-than ordinary standard of normal, 
       security, and cryptographic operations with the care 
       appropriate to the value the Membersite assigns to the 
       business it conducts (or wishes to conduct) with the 
       Homesite. 

       As such, certain requirements might be [globally] 
       prerequisite for operating a Homesite, or the protocol 
       might provide a way to specify or discover such. There
       might be a need for a standard way for principals to
       describe what they intend, wrt the Membersite, or the
       Homesite, regarding "responsibilities for authentication
       and identifying the user, maintaining a repository of
       identity data, releasing that data, obtaining (certain)
       user consent" [abstract from dmd00]. Any assumed, or 
       unstated, requirements in this respect might limit the 
       scope of operation even if technical interoperability 
       were possible.
 
       (Tentative and partial, although the requirement in
       dmd00 implies capabilities as PG/Gs which would be 
       dependent on or assume this.)

       By comparison, whereas (in general) PDC3 pertains to the 
       security concerns relative to the Membersite user of
       the current transaction, PDC6 pertains to the security 
       concerns of the Membersite as a whole as a relying party 
       to that particular Homesite. Of course these are related,
       but PDC3 relates to protocol exchange; PDC6 relates to
       criteria about and surrounding the protocol itself and
       the entities that would offer the services.

 PDC7. The protocol should be built to accommodate (natively or 
       through use of native extension points) SAML tokens. 

       (Tentative and partial)

       A bit of definition is required here. 

       Dick, what do you mean by "SAML token": SAMLRequest and 
       SAMLReply objects? SAMLAuthnRequest, SAMLAssertion? 

       There are further implications associated with any
       complete definition of the ability you mention when
       you say "SAML tokens could be moved around by DIX."
       I haven't tried to straighten that out here. 
       Perhaps you could elaborate (in a separate thread:-)?

Dick contined:
> >
> >     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.
> >
> > Dick Hardt wrote:
> >> 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

Hum ... well there are two parts to that. The first just doesn't
rise to the level of the proposed effort: if your web app doesn't
need more than to just get some name-value pair injected into 
your login form, then you don't need dix or anything like it.
That's a definition of "simple" I can design to.

But (part two) if as a relying party/Membersite you need more than 
that, then there's a requirement or two ... scaled to your needs 
(some specified above). dmd00 in the least imposes these 
requirements on the 'application' it calls the Membersite:

* Membersite must be aware of the existence of a Homesite,
  in the least to address the request there, yes? 
* To request that a user identify their Homesite, using an
  appropriate HTML form control
* To make that into a cookie using the appropriate name=value 
  pair
* To later retrieve that cookie and use the appropriate name=value
  pair. 
* To direct a request to a Homesite, if necessary retrying at 
  least once and dealing with redirects.
* To retrieve endpoint and capabilities information
  proceed to endpoint, possibly also requiring discovery of 
  that endpoint and capabilities of the Homesite
* To form the HTTP POST for redirect with appropriate verification
  and cryptographic features
* To maintain in pendency the user's requested session at the 
  Membersite
* To verify the response message from the Homesite

and more. That looks to me like a bit more than:

> "added ... without any code change, just additional HTML"

So, how am I not correct, then, in concluding that for any effort 
that would rise to a community effort, this protocol must be 
designed to account for "making the application aware of identity 
attestations of a trusted third party"?

Dick continued:
<NR:From my 25Jan06 messing I've clipped the details of the 
    hypothisized "SAML-LowLow>
> >
> > NR: Right off this is indeed heavier. But what's the 
> > *objective* bar?
> 
> Really simple to implement. :)

I'll take that grin as a nod that we might want to get a bit more 
specific about that "objective test." 

I note that the list has had a bit more chatter about this. I 
encourage us to think a bit more specifically and fully about the 
question. 

"Simple," "easy-to-implement," "light," "consumable," "not complex," 
even what 'code' would be considered "in" vs "out" of the entire 
solution (therefore part of the 'bug pool') ... all or any of 
these still require agreement before they mean anything useful. 
Especially if we are to design for the possibility of supporting 
in the proposed protocol the 'any ole name=value pair' type 
relying party, as well as one that might be as serious to ask 
about two-factor authn (as in the example in dmd00). 

Consider, perhaps, that having presented the above PG and PDC, we 
now recognize that there are quite a few requirements on the 
Homesite to be prepared for pertaining a request from the
Membersite (who is, ultimately, in control of the question). 

We hear the protocol is supposed to rise to the level of responding 
to a Membersite that expects true assurances that the Homesite 
really does carry out operations that assure 'true' member's consent,
or even more, desires two-factor authentication. 

Then the burden is certainly higher than just any ordinary host: 
keep up to date on security updates (including any new tool chain 
recompiles), maintain firewalls, control data repositories, etc. 
These aren't minor or out-of-scope to the use of the protocol; 
they are intrinsic with standing up, e.g., dmd00, AFAICT. 

In that context, then, what is the objective test that separates
these issues? An unelaborated "Simple" isn't good enough for this 
domain, particularly for a community-developed standard.

The question is even one of "where?" Over the wire? Or within
the Homesite, or Membersite for the developer? And for whom?
On this latter question, it appears it can only be wrt the
developer at a Homesite or Membersite who develops the code
incantation that 'users' put in their cgi.

Even the PG1 seems a bit disconnected to the intrinsic requirements: 
If you are a Perl developer (who must also meet all the operations 
requirements, above), what's the objective difference *for the 
developer in a system otherwise meeting the environmental requirements* 
between (installing and maintaining and) 'use'ing CGI :form or :html 
and 'use'ing XML::Simple (both mostly just assigning suitably-named 
hashes and attributes) for the type of processing we're discussing? 

Even at that, if we're just talking about over-the-wire, well, 
fine. Perhaps at some level an existing protocol can address that.
Then we might get closer to understanding the innovations and
value of a new effort. See: "SAMLv2-LowLow, bindings and profiles?"
thread.

Dick continued:
> >     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?

Now I don't understand. 

What candidate form generators *don't* allow developers to add this 
data to a form? What candidate form generators *don't* operate in a 
domain where timestamps and request-response identifiers can't be 
sustained? These are the two principal 'additions' that comprise 
that "extra."

Dick continued:
> 
> >     Beyond that this "SAML-LowLow" profile could even be lighter,
> >     if that’s what's required. Such as removing the Authentication
> >     ...snipped
> 
> 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.

Getting clarity seems like a reasonable community effort. Getting 
toolkits does as well. 

If we can identify distinct and clear gaps that can't be corrected
from the pool of existing community work, then innovations in those
areas seems like a really good idea too. (I think that DIXUFFEML 
(digital identity user form factor expression markup language)
bit would be really useful, and sufficiently challenging, and
distinct, work.)

Recapitulation and creating another isolated security exchange 
doesn't seem like such a good thing.

Best,
--Nick

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

---

From: John Merrells <[email-masked]>
Date: Mon, 20 Feb 2006 21:13:01 -0800

Taking me a while to digest all that Nick. But, to pick off one small
bit to chew on a bit...

> incantation that 'users' put in their cgi.

The way I think about it is this... The goal is adoption... How do
we get all parties to buy into talking this protocol, for the good
of all. So, the parties are (using the dmd0 terms that I'm most
familiar with: The User, The Homesite Developer, and The
Membersite Developer. In my opinion the simplicity priorities
are:

1) The User
2) The Membersite
3) The Homesite

All complexity moves from the User to the MS to the HS... to
the point of there being nothing to install on the user's machine,
and for a Membersite being enabled with just some HTML
editing.

John

---

From: John Merrells <[email-masked]>
Date: Mon, 20 Feb 2006 21:28:25 -0800

Had to truncate that subject.

>       handling HTML and working with name-value pairs is

The driver here is simplicity for the Membersite.

XML's just lovely, and as simple as it started out it now has its own
complexities. For representation of attribute value assertions with
values of simple types it's more than is required. A name-value
pair is enough. The result is no requirement for XML handling at
the Membersite.

If a MS and HS wanted to exchange complex types, then yes
there needs to be some way of structuring that data, and XML is
one the obvious way to do that. There could be others. This
could easily be layered on top of the basic protocol. Perhaps by
extending an extensible property name and type mechanism.

(This is intended in dmd0 via the Property Capability mechanism,
although how property types are defined is left as an exercise
for the reader ;-)

John

---

From: John Merrells <[email-masked]>
Date: Mon, 20 Feb 2006 21:53:11 -0800

>  PG2. Existing protocol SAMLv2 is heavy; we want light.

Well 'heavy' and 'light' aren't very rigorous... but I'd say this goes
back to the adoption goal: 'How do we get an internet wide identity
protocol into everyone's hands as quickly as possible?'

As a slight aside, in your 'Setting aside irrelevant or incomplete
histories' post you had lots of nice data points about SAML deployments.
Enlightened me actually. SAML's clearly offering people enough
value that people are building businesses around it and it's being
deployed by big corporations. But... in all my years of Internet surfing
I've never come across a website that said 'Take me to your IdP...', or
'Can I be your Idp...' Never. Am I just cruising the web with my
blinkers on?

There's something about SAML that's meant that developers of
the websites that I frequent haven't chosen to deploy it. Why is
that? That's kinda rhetorical, but I don't want to rant about why
SAML doesn't work for me as a User, Membersite or Homesite
developer, I'd rather one of them stood up and said it.

I think we need to drill into the reasons for PG2.

John

---

From: John Merrells <[email-masked]>
Date: Mon, 20 Feb 2006 22:00:10 -0800

>  PG3. We don't want to use XML-DSIG.

Not that we don't want to, just that it's more than is required.

The minimum requirement is to be able to exchange an attribute value
assertions between Homesites and Membersites. That's enough to
exchnage self-asserted values, either simple types as literals or  
complex
types as XML.... and also enough to exchange third-party asserted
values as digitally signed values, which could be XML-DSIG.

So, if required, could be layered on top, but don't need to be in the
lowest layer of protocol, lest they hamper adoption, which we at
Sxip found that they did.

John

---

From: John Merrells <[email-masked]>
Date: Mon, 20 Feb 2006 22:39:22 -0800

Will work though these myself asap, but am a bit tired and have to  
get up early tomorrow.

Would love to hear what other's think of these points extracted by Nick.

John

---

From: Peter Davis <[email-masked]>
Date: Tue, 21 Feb 2006 12:09:02 -0500

On 2/21/2006 12:53 AM, "John Merrells" <[email-masked]> wrote:

> But... in all my years of Internet surfing

That's because good SAML deployments make this a seamless experience for the
user ;-).

The impediments for deploying federated architectures have little to do with
technology.  Federated identity management introduces new business and legal
complexities which many are only now coming to terms with.  The technology
is there, in a number of forms (which is why I'm loath to add yet another
form unless it's absolutely necessary).

=peterd  (http://xri.net/=peterd)

---

From: Jeff Hodges <[email-masked]>
Date: Wed, 22 Feb 2006 06:38:33 -0800

are you attending Dallas IETF?
just curious. I'll be there.

JeffH

---

From: John Merrells <[email-masked]>
Date: Sun, 26 Feb 2006 20:29:21 -0800

> That's because good SAML deployments make this a seamless  

For sure, the tech should be under the covers, and the user's should
just experience the benefits. But, I've never experienced the benefit
of SAML on the web. Nick's big list of deployments suggests that I
would have to be a Boeing employee who banks with Wells Fargo.

(And I strongly suspect that even though both have deployed some
form of SAML that there's no way for a user to actually move anything,
between them... )

> technology.

I think there clearly is a technology issue here. With the SAML
protocol I don't see how you move a token between parties
who don't already have a pre-existing relationship.

> Federated identity management introduces new business and legal

Although the technology exists in the form of SAML/Liberty/Shibboleth
and had been deployed by large enterprises/universities... I don't see
any uptake in the internet space from the huge portals and commerce
web sites down to the one person part-time websites. To me there's
clearly an adoption issue. Scalability at one end and availability and
usability at the other.

If anyone has data points that suggest otherwise please share them.

John