Subject: [dix] draft-merrells-dix-02.txt

From: John Merrells <[email-masked]>
Date: Thu, 1 Jun 2006 12:08:56 -0700

Hello,

We've been busy working away in the background reworking the protocol
draft. As a result of the feedback at the IETF 65 DIX BOF we have recast
much of the DIX protocol as SAML messages, assertions, and profiles.

As ever we'd welcome your feedback on this draft.

John

Changelog Highlights

    Request and Response messages now encoded as SAML messages.
    Replaced DIX URIs with URNs.
    Renamed Membersite as Service Provider.
    Renamed Homesite as Identity Agent.
    Renamed Capability to Service.

ID

    http://dixs.org/index.php/Draft-merrells-dix-02.txt

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

---

From: John Merrells <[email-masked]>
Date: Thu, 1 Jun 2006 13:22:49 -0700

> http://dixs.org/index.php/Draft-merrells-dix-02.txt

That was a wiki html page.

This is the ID as a .txt file.

http://dixs.org/documents/draft-merrells-dix-02.txt

This is the ID as a .html file.

http://dixs.org/documents/draft-merrells-dix-02.html

John

---

From: Jeff Hodges <[email-masked]>
Date: Sun, 04 Jun 2006 20:43:08 -0700

I have some comments on draft-merrells-dix-02. I'll touch on only the
first-order ones in this message -- there are various detail-level issues I've
noticed, but I'd rather discuss the former first.

Although it is good (for various reasons) that this spec has been recast
nominally in the form of a "SAML profile", I don't feel it is, as presently
written, actually one.

Rather, the spec is written more in terms of attempting to wedge a slight
veneer of SAML into the SXIP framework. For example, retaining the "DIX 
protocol" terminology, as is done in section 3, and in the entitling of section 
4.3 as "Employing SAML in DIX", is symptomatic.

Specifically, rather than appropriately reusing the SAML Authentication Request 
Protocol and the SAML Assertion Query and Request Protocol, 
draft-merrells-dix-02 invents its own Fetch protocols and messages (which are 
analogous to the former SAML abstract protocols), only cursorily basing them 
upon the SAML RequestAbstractType. These protocols do not reuse the notion of, 
and elements for, "Subject"s -- rather, inventing their own top-level elements 
for naming of entities (eg "SPName").

Since SAML presently doesn't have a notion of a "store" protocol, it is 
reasonable to invent such, though I believe one could design it such that it 
intersects more fully with SAML approaches.

Furthermore, the notion of SAML assertions as a means of concisely conveying
Subject information is not directly employed. SAML assertions are nominally
profiled in draft-merrells-dix-assertion-00, but, for example, are not actually 
employed in draft-merrells-dix-02.

The reasons these points matter are at least..

* established SAML semantics largely aren't employed - thus all the added-value 
security knowledge-base that they represent is not leveraged

* crafting implementations facilitating convenient re-configuration to
"turn security on" isn't facilitated (i.e. security mechs other than those 
sxip-derived ones that are in the spec)

* ditto for facilitating "turning on identity federation"

This is a serious "lose", in my view.

As such, although they are a "SAML profile" in some small, nominal fashion, 
these specs are _not_ in my view crafted in the terms of the present family of 
SAML profiles, and thus will tend to foster divergence rather than convergence.

I suspect it is possible to craft a lightweight SAML web SSO profile that can 
support the sxip features (eg the signing approach) desired by some, and also 
support other, more conventional signing approaches (but not use xmldsig) -- 
both of which can be optional so it can be deployed in ultimate lightweight 
fashion if desired. This profile, designed with established SAML semantics and 
approaches, will then facilitate deployments' migration (perhaps even by 
reconfiguration) to more robust security and identity federation if desired.

JeffH

---

From: John Merrells <[email-masked]>
Date: Sun, 4 Jun 2006 20:51:03 -0700

On 4-Jun-06, at 8:43 PM, Jeff Hodges wrote:

> veneer of SAML into the SXIP framework. For example, retaining the  
> "DIX protocol" terminology, as is done in section 3, and in the  
> entitling of section 4.3 as "Employing SAML in DIX", is symptomatic.

Which terms do you mean? I actually switched from Homesite/Membersite
to Identity Agent/Service Provider as they seemed more inline with SAML.

Actually the 4.3 title is a holdover from the text I stole from your  
SAML
over SIP draft :) What do you think it should be called?

John

---

From: John Merrells <[email-masked]>
Date: Sun, 4 Jun 2006 20:56:59 -0700

On 4-Jun-06, at 8:43 PM, Jeff Hodges wrote:

> Subject information is not directly employed.

I'm currently looking into how we can reuse Subject and Subject  
Confirmation to carry our Persona URL and to signal that it should be  
verified using the lighter weight signing mechanism.

> SAML assertions are nominally
> profiled in draft-merrells-dix-assertion-00, but, for example,

'nominally'? Meaning not enough?

> are not actually employed in draft-merrells-dix-02.

Intentionally, the assertions are an example of a claim format that  
could be used for moving around third party attested attribute value  
assertions.

John

---

From: John Merrells <[email-masked]>
Date: Sun, 4 Jun 2006 20:53:54 -0700

On 4-Jun-06, at 8:43 PM, Jeff Hodges wrote:

> Specifically, rather than appropriately reusing the SAML  
> Authentication Request Protocol and the SAML Assertion Query and  
> Request Protocol, draft-merrells-dix-02 invents its own Fetch  
> protocols and messages (which are analogous to the former SAML  
> abstract protocols), only cursorily basing them upon the SAML  
> RequestAbstractType.
>
> Since SAML presently doesn't have a notion of a "store" protocol,  
> it is reasonable to invent such, though I believe one could design  
> it such that it intersects more fully with SAML approaches.

Our first crack at the fetch request message was exactly as you  
suggest, but then we realized that the Store request would have to be  
different... so we ended up switching the fetch to the same scheme to  
make them more orthogonal.

> These protocols do not reuse the notion of, and elements for,  
> "Subject"s -- rather, inventing their own top-level elements for  
> naming of entities (eg "SPName").

Where would you expect 'SPName' to appear?

John

---

From: John Merrells <[email-masked]>
Date: Sun, 4 Jun 2006 21:00:16 -0700

On 4-Jun-06, at 8:43 PM, Jeff Hodges wrote:

> * established SAML semantics largely aren't employed - thus all the  
> added-value security knowledge-base that they represent is not  
> leveraged

For example?

> "turn security on" isn't facilitated (i.e. security mechs other  
> than those sxip-derived ones that are in the spec)

I think that it is, just isn't documented. If it were documented  
better you'd be happy?

> * ditto for facilitating "turning on identity federation"

I'm not sure what that means.

John

---

From: John Merrells <[email-masked]>
Date: Sun, 4 Jun 2006 21:02:35 -0700

On 4-Jun-06, at 8:43 PM, Jeff Hodges wrote:

> I suspect it is possible to craft a lightweight SAML web SSO  
> profile that can support the sxip features (eg the signing  
> approach) desired by some, and also support other, more  
> conventional signing approaches (but not use xmldsig) -- both of  
> which can be optional so it can be deployed in ultimate lightweight  
> fashion if desired. This profile, designed with established SAML  
> semantics and approaches, will then facilitate deployments'  
> migration (perhaps even by reconfiguration) to more robust security  
> and identity federation if desired.

I think that DIX is moving to becoming that. I've reused (based your  
advise, and Scott's and Bob's) as much SAML as I could whilst still  
maintaining the goals we've established for this work. If there's  
more SAML we can reuse than I'd greatly appreciate your expertise,  
guidance and support in making that a reality.

John

---

From: John Merrells <[email-masked]>
Date: Mon, 5 Jun 2006 10:49:28 -0700

> naming of entities (eg "SPName").

I don't see how these are related. SPName is in the request and is  
the identifier of the service provider, whereas Subject would be the  
identifier of the user, their Persona URL. Yes? I can't find an  
equivalent for SPName in SAML... the closest thing would be  
AssertionConsumerServiceURL, but I'm putting that into Issuer.

John

---

From: John Merrells <[email-masked]>
Date: Mon, 5 Jun 2006 14:00:13 -0700

On 4-Jun-06, at 8:51 PM, John Merrells wrote:

>> and in the entitling of section 4.3 as "Employing SAML in DIX", is  
>> symptomatic.
>
> Actually the 4.3 title is a holdover from the text I stole from  
> your SAML

I've renamed it 'Profiling SAML for DIX'.

John

---

From: Jeff Hodges <[email-masked]>
Date: Mon, 05 Jun 2006 16:22:31 -0700

Sorry am at a conference for a few days, plus little league playoff games, so 
responses will have higher than my already high latency.

 > I've renamed it 'Profiling SAML for DIX'.

As of yet, nobody's attempted to concoct catchy names for SAML profiles. If 
you're set on doing so, eg using "DIX", I'd do it like so..

   "DIX: A Web Browser SSO SAML Profile"

JeffH

---

From: Jeff Hodges <[email-masked]>
Date: Mon, 05 Jun 2006 16:32:56 -0700

Jeff Hodges wrote:
 >
 > As of yet, nobody's attempted to concoct catchy names for SAML profiles.
 > If you're set on doing so, eg using "DIX", I'd do it like so..
 >

that's not to say, tho, that I think the spec as presently constituted is a 
SAML profile in the spirit of other present SAML profiles, as I noted in my 
prior msg.

JeffH

---

From: John Merrells <[email-masked]>
Date: Mon, 5 Jun 2006 17:03:22 -0700

On 5-Jun-06, at 4:22 PM, Jeff Hodges wrote:

> As of yet, nobody's attempted to concoct catchy names for SAML  
> profiles. If you're set on doing so, eg using "DIX", I'd do it like  
> so..
>

It's not just for SSO though, as the fetch is designed for moving  
both authentication and/or attribute assertions, either self  
asserted, or third-party asserted. And although the binding in the  
dmd draft is based on HTTP/HTML the messages could be mapped onto  
alternative transports. So I'm not sure what to call it... 'DIX SAML  
Profile'.

What is the collective term for a set of SAML profiles, and bindings,  
etc... is that itself a Profile?

John

---

From: John Merrells <[email-masked]>
Date: Mon, 5 Jun 2006 17:11:20 -0700

On 5-Jun-06, at 4:32 PM, Jeff Hodges wrote:

> that's not to say, tho, that I think the spec as presently  
> constituted is a SAML profile in the spirit of other present SAML  
> profiles, as I noted in my prior msg.

That's due to incompetence rather than any malaise on my part.

I'm trying to reuse as much of SAML as I can whilst still satisfying
all the DIX goals and use cases.

The next revision of the draft (dmd3) now includes Subject in the
Fetch Response Message and registers a Subject Confirmation
Method for Persona Delegation Verification.

John

---

From: Robert Yates <[email-masked]>
Date: Tue, 06 Jun 2006 18:32:16 -0400

> As ever we'd welcome your feedback on this draft.

The new draft with the SAML mapping seems to me to be harder to follow 
than the last, but having said that you seem to have done a great job of 
keeping the SAML complexity to a minimum.

I was a little disappointed to see it explicit that non browser clients 
are not being considered, feedreaders and blog clients seem extremely 
important to me and I worry about leaving them out.  It will be 
interesting to see if they are accomodated in WARP and whether Sam is 
going to propose some sort of federated digest authentication scheme, 
potentially similar to the one proposed by Philip 
http://www1.ietf.org/mail-archive/web/dix/current/msg00368.html. 

A scheme such as this would benefit from sharing a common definition of 
persona-url and persona-document with DIX. Has there been any discussion 
on moving the persona-url and persona-document definitions out of the 
DIX protocol specification and into its own specification. They seem 
more broadly useful and the corresponding specification can build on the 
Yadis work. Are any of the Yadis folks thinking of submitting a draft to 
the IETF?

Rob

---

From: John Merrells <[email-masked]>
Date: Tue, 6 Jun 2006 15:47:38 -0700

On 6-Jun-06, at 3:32 PM, Robert Yates wrote:

> The new draft with the SAML mapping seems to me to be harder to  
> follow than the last, but having said that you seem to have done a  
> great job of keeping the SAML complexity to a minimum.

Thanks. It's not that easy. This draft is +20 pages longer, and  
there's still more detail to drill into. :-(

> I was a little disappointed to see it explicit that non browser  
> clients are not being considered, feedreaders and blog clients seem  
> extremely important to me and I worry about leaving them out.

Just a lack of bandwidth. The scope of the group should be no wider  
than there are authoring teams to write documents and code. It'd be  
great if you want to put together a team to address the use cases you  
care most about.

I have a draft of how an Identity Agent Application would work, which  
would provide some insight there perhaps. I hope to get that out in  
the next couple of weeks.

> Has there been any discussion on moving the persona-url and persona- 
> document definitions out of the DIX protocol specification and into  
> its own specification.

No, but that occurred to me, which is why I've structured the  
document so that the Persona URL is entirely in it's own section.  
(Microformat...?)

John