Subject: RE: [dix] Re: attribute assertions

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 18 Jan 2006 08:22:38 -0800

I think that we need to provide a ready to run proposal not the
equivalent of DIY flat pack furniture.

Security negotiation protocols are a very bad idea, in almost all cases
the result is that the security of the system is the security of the
weakest link in the chain. We really need to be selecting components
that work together, not designing a system that panders to every legacy
idea out there.

BEEP for example, zero traction in the commercial Web Services world,
negligible traction in the open source world, should be moved to
historical. Same goes for XML-RPC. 

One of the hazzards of standards processes is having another group that
has no deployment momentum capture your proposal and insist on turning
it into their deployment vehicle. The BEEP author tried to do this to
SACRED. The DNS people tried with MARID and will try again with DKIM. 

Network protocol standards have very strong network effects, unless we
are dealling with emerging protocols (SAML for example) the winner
should be clear. I don't think we should deliberately preclude
alternatives, but we do need to have a 'must implement' profile that
provides compatibility.

I would add format of the identifier at the top of the list. The design
of the identifier will affect everything else.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Suresh Venkatraman
> Sent: Tuesday, January 17, 2006 11:04 PM
> To: 'Digital Identity Exchange'
> Subject: RE: [dix] Re: attribute assertions
> 
> OK - so, at a high-level, what areas, in the "proper 
> terminology", can we say are or are not part of DIX? Off the 
> top of my head and in no particular
> order:
> 
> * Location Discovery (of the ID-Service)
> * Validation (of the ID-Service)
> * Negotiation (Content, Encoding, Language, Security, Algorithms)
> * Common Identity Scheme (URI's, URL's, XRI's, etc.)
> * Identity Authentication (e.g. one-time passwords, digest, pki, etc.)
> * Identifier Exchange (Claims, Mappings, etc.) - Addressed in SAML?
> * Bindings (HTTP, SMTP, SIP, etc.)
> * Security Layers - Compatible with by TLS, SASL, BEEP, etc.?
> * Federation (Unifying the Namespace)
> 
> Many of these areas are already addressed by existing RFC's 
> and can be folded into the DIX framework (when one exists).  
> In addition has anyone come up with a list of use cases for 
> DIX? Thanks.
> 
> Suresh
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dick Hardt
> Sent: Tuesday, January 17, 2006 6:59 PM
> To: Digital Identity Exchange
> Subject: Re: [dix] Re: attribute assertions
> 
> 
> On 17-Jan-06, at 6:48 PM, Hallam-Baker, Phillip wrote:
> 
> >> From: [email-masked] [mailto:[email-masked]] On
> >
> >>> What about HTTP Accept headers? That is discovery...
> >>
> >> "HTTP-Accept" is for discovery of acceptable media types within a 
> >> particular HTTP session. Like the example from RFC 2616:
> >>
> >>     Accept: audio/*; q=0.2, audio/basic
> >
> > The terminology used in the HTTP spec describes it as a negotiation 
> > protocol, there are negotiation mechanisms for content type and 
> > encoding.
> >
> > It is important to keep to the established terminology as there are 
> > people on the IESG who will pick it to pieces otherwise.
> 
> Good point.
> 
> I would add Negotiation then as another part of the process, 
> separate from Discovery.
> 
> _______________________________________________
> dix mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dix
> 
> 
> 
> _______________________________________________
> dix mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dix
> 
> 

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

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Wed, 18 Jan 2006 11:35:14 -0800

> that work together, not designing a system that panders to every legacy

I'm not suggesting that DIX tackles the security problem; what I am
suggesting is that whatever mechanisms are chosen for DIX cannot preclude
the use of existing ready-to-run security layers such as TLS, SASL
mechanisms, or digest-authentication. OTOH, if security is not given any
consideration then we might as well quit now.

> historical. Same goes for XML-RPC.

I agree - anything that has zero traction today should not be included. I'm
am also of the same mind as far as building something that can be
implemented today and work across multiple services, both entrenched (HTTP)
and emerging (SIP). Currently there's a big fight between SAML and
WS-Federation, I think we have to choose one to make this work (SAML), but
leave the exchange language extensible. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hallam-Baker, Phillip
Sent: Wednesday, January 18, 2006 8:23 AM
To: Digital Identity Exchange
Subject: RE: [dix] Re: attribute assertions

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Jan 2006 12:55:34 -0700

> consideration then we might as well quit now.

<snip/>

> leave the exchange language extensible. 

Given that XMPP (RFC 3920) is built atop TLS and SASL, it might be a 
good option for the transport protocol. But I'm biased.

Peter

---

From: Dick Hardt <[email-masked]>
Date: Wed, 18 Jan 2006 12:00:56 -0800

On 18-Jan-06, at 11:55 AM, Peter Saint-Andre wrote:

> Given that XMPP (RFC 3920) is built atop TLS and SASL, it might be  
> a good option for the transport protocol. But I'm biased.

In the ID that John Merrells posted, HTTP is the transport being  
discussed.

No reason for DIX to not run on XMPP or SIP. Would be *good*  
objectives for that to be possible.

-- Dick

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Wed, 18 Jan 2006 12:22:02 -0800

> objectives for that to be possible.

I'd say there are quite a few options available:

(1) Create DIX as a transport independent protocol and spec bindings for
multiple protocols (HTTP, SIP, XMPP, etc.). This is what the Merrell draft
proposes.

(2) Make DIX protocol specific, let's say by adding extension methods to
HTTP - this might be a bad idea as we could get lumped into the Network/HTTP
working group. Just throwing it out there...

(3) Create a separate request/response protocol for DIX taking into account
the specific needs of identity exchange, authentication, etc. This would
need bindings for multiple protocols as well to ensure interop.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick
Hardt
Sent: Wednesday, January 18, 2006 12:01 PM
To: Digital Identity Exchange
Subject: Re: [dix] Re: attribute assertions

-- Dick

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Jan 2006 13:32:53 -0700

> multiple protocols (HTTP, SIP, XMPP, etc.). This is what the Merrell draft

That always seems like a good idea to me.

Peter

---

From: John Merrells <[email-masked]>
Date: Wed, 18 Jan 2006 13:54:55 -0800

> multiple protocols (HTTP, SIP, XMPP, etc.). This is what the  

Yep, the proposed charter details two documents: 'DIX Protocol' and 'DIX
over HTTP'. If people want to work on others that'd be great.

XMPP looks like a great option.

SIP too, but I don't personally have any experience of working with  
it. If
there's anyone on the list with an intersection of interests between SIP
and DIX who wants to liaise between the groups... or author a 'DIX over
SIP' draft that'd be cool.

> working group. Just throwing it out there...

I think that the HTTP-AUTH group would be the right place for this
conversation.

> need bindings for multiple protocols as well to ensure interop.

Sounds like (1) to me. How's that different?

John

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 18 Jan 2006 14:18:17 -0800

For certain parts of this ecosystem, more transports is not better.  
Forgive me if this is already obvious to others (and correct me if I'm 
wrong)...

For the client --> content server communication, more transports is 
better as "single sign on" vision is to work for email, IM, Web, voice 
and other applications -- so in the long run this would work with the 
application protocols that clients already use.

For the client --> authentication server communication, a low number of 
transports is highly desirable, so that an arbitrary client has a good 
chance of working against authentication servers from different 
providers. However there may be need for more than one, and we may be 
able to make that work by saying that an auth server implementing 
such-and-such a spec MUST implement all the required transports

For all other pieces between servers, a low number of transports is 
desirable as well, particularly because you can model the content 
server as a kind of client against the authentication server or other 
servers; the content server might be deployed by 3rd parties and small 
shops, and not be under the same IT as the authority servers.

lisa

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Wed, 18 Jan 2006 14:35:46 -0800

> such-and-such a spec MUST implement all the required transports

That was kind of why I brought up the third option, however unlikely it
seemed to introduce a new protocol. Of course the overhead of building yet
another protocol may be too much given the proposed timeline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lisa
Dusseault
Sent: Wednesday, January 18, 2006 2:18 PM
To: Digital Identity Exchange
Subject: Re: [dix] Re: attribute assertions

lisa