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