Subject: RE: [dix] Bfcasr - PG2

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Feb 2006 08:57:47 -0800

> From: John Merrells [mailto:[email-masked]] 

> 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.

Possibly, but this is simply a consequence of the way that network
protocols are deployed. To get traction you have to aggressively court a
tightly focused early adopter community. That does not mean that the
protocol is only designed for that community, it does mean that you are
most likely to find early adoption there.

Obviously we were not designing a single sign on scheme for the
blogosphere in 2002.

Most of the companies who showed up for the SAML kickoff were vendors
selling enterprise class products or services. That is where the market
was in those days. From the very first meeting it was apparent that
there was a huge number of people involved, 60 to 80 in the first WG
meeting. There was thus a very understandable desire to try to keep the
scope tightly focused. 

I think that DIX is doing something different but it can certainly be
something complimentary. I would like DIX to reuse components from SAML
and WS-* wherever that makes sense. 

If DIX is going to be used with attributes supplied by trusted third
parties then DIX code is going to have to accept attributes in the
form(s) supported by the commercial TTPs. At this point the only formats
that I am aware that commercial TTPs support or are planning to support
are X.509v3 certificates and SAML assertions. 

> 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.

That depends on how you configure the system. The SAML spec sets out a
series of use cases that the spec is designed to support. That does not
mean that they are the only use cases the spec supports as written.
There was quite a bit of argument over which use cases should be
included, more argument than we had over the protocol design which was
taking place independently.

SAML is designed to support a strong federation model where the user,
the authentication service and the relying party can interact according
to many different accreditation models.

In DIX the problem of establishing trust between the authentication
service and the relying party is essentially finessed by reducing the
problem to a single communication pattern.

Given where we are starting from I think that the most likely response
from the IESG here is going to be 'go write a requirements document', it
is certainly what I would request if I was making the decision and was
not otherwise involved.

I would then want to see a demonstration that each piece of new
mechanism required in DIX is justified by a clear need.

I think that there are clear justifications for certain DIX innovations:

* The SAML assertion format is designed to support signed assertions
using XML Signature. The overhead required is certainly justified when
dealling with TTP assertions where the attributes are trusted and must
be trustworthy. URI form encoding is much simpler and easier to manage
and equally useful when the data is originally self asserted.

* The use of a uniform identifier for identity is a key architectural
innovation. SAML supports the use of a uniform identifier but there is a
huge difference between support for a feature and designing a system
around a feature. 

When WS-* was first introduced people were determined to see a
competition between the two. Today most people agree that there is a
need for different approaches for different applications. WS-* is
essentially a no-compromises system designed to provide the best
possible security infrastructure for Web Services. It can also be used
for other purposes and used standalone but the architecture does not
make concessions that are designed to encourage early adoption for that
application.

The objective here is to establish an open identity system for the
Internet. DIX, SAML, WS-* are merely means to that end. I am quite happy
if it turns out that the output of DIX turns out to be a protocol that
is mostly used as a transitional technology; a scafolding that allows
the more ambitious schemes to be built more quickly.

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

---

From: John Merrells <[email-masked]>
Date: Mon, 27 Feb 2006 09:51:16 -0800

> and WS-* wherever that makes sense.

I agree.

> are X.509v3 certificates and SAML assertions.

Also agree.

> is certainly what I would request if I was making the decision and was

Sure, the draft charter includes a milestone for a use-case draft,
which I think serves as requirements.

> be trustworthy.

Yes.

> URI form encoding is much simpler and easier to manage

Yes.

> huge difference between support for a feature and designing a system

Yes

> make concessions that are designed to encourage early adoption for  

The environment for WS-* seems different. Economically it's a two
party platform... the desktop and the server... but Microsoft can
leverage it's installed base and development tools to make sure
it's at both ends everywhere.

> the more ambitious schemes to be built more quickly.

Me too, and I think that dmd0 reflects that. All it really does is
some discovery and then the movement of a blob between
two parties.

John