Subject: [dix] draft of proposed charter (#2)

From: John Merrells <[email-masked]>
Date: Thu, 19 Jan 2006 12:46:21 -0800

Reworked to take into account the comments received so far. There's  
still a
couple of outstanding comments... and am waiting for those threads to  
close
out... today I hope :-)

John

----

Proposed Charter for DIX Working Group

Digital Identity Exchange - DIX

Chairs

TBD

Applciations Area Director(s):

Ted Hardie <[email-masked]>
Scott Hollenbeck <[email-masked]>

Mailing Lists:

General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/dix/

Description of Working Group:

The DIX group will work on the specification of the Digital Identity  
Exchange protocol. DIX is an Internet scale protocol for exchanging  
identity information between endpoints. The protocol architecture  
maintains a separation of control between all parties of the exchange  
and supports both compartmentalized and anonymous identities.

Problem Statement

The success of the Internet has led to a multitude of online  
information sources and services. A consequence of this has been the  
increasing demand for users to identify themselves and to provide  
information about them. The user is currently bearing the burden of  
managing their authentication credentials and is repeatedly having to  
provide their identity information. For example, signing in to web  
pages and completing user registration forms.

Goal

The goal of this group is to specify a protocol for moving identity  
information between parties and a system architecture that enables  
the development of software agents to manage the exchange of a user’s  
identity information.

Method

An identity information exchange should involve just three parties:  
the user, their agent, and a relying party. The user’s agent is where  
they authenticate themselves and a repository where they store their  
identity information, and the relying party is an entity requesting  
identity information.

The protocol should be both simple and secure. Simple meaning that  
minimal modifications should be required to the user’s software and  
the relying party’s software to participate in an identity  
information exchange. The protocol should be inherently scalable,  
requiring no centralized services, beyond those that already exist,  
in order to operate.

The security of a protocol is well understood within the IETF to be  
the assurance of confidentiality and integrity of any transferred  
information. But, in the context of digital identity we wish to also  
be assured that user’s agents and relying parties maintain user privacy.

Any solution should support multiple transport layers, including, but  
not limited to: HTTP, SOAP, XMPP, and SIP. It is anticipated that  
this working group will initially focus on a HTTP based solution.

In moving identity information between parties it is expected that  
the messages of the protocol will include elements that bind property  
names and values to digital identities. How a digital identity is  
referred to is an important consideration. The properties an  
identifier could have are that it allows the user to concurrently  
maintain multiple personas, that it could allow for a separation  
between the digital identity and the identifier and that it allow for  
separation between the identifier and the user’s agent. In the  
interests of flexibility and interoperability we would suggest that  
the identifier be a string of characters. This working group may  
consider current best practice of what that string might be. For  
example, a URI, a URL or a UUID.

Work In Scope

A user-centric, simple, secure, interoperable protocol for digital  
identity information exchange.

An advanced work item for this working group would be consideration  
of how this protocol could operate over web services protocols (e.g.  
SOAP, XML-RPC, REST), or interoperate with existing web services  
protocols for security information (e.g. WS-Trust). The group must be  
careful not to preclude interoperation at a later date.

Although the data that represents the identity information is  
expected to be opaque it is worth mentioning that the data could be  
raw attributes of the digital identity, or could be third party  
claims. A third party claim is signed by an authoritative source so  
that the relying party can be assured of its authenticity. The  
benefit of third party claims, as supported by this protocol, is that  
the separation of claim acquisition from claim presentation provides  
both scalability and privacy benefits.

Out of Scope

How to federate identity namespaces.
How to manage digital certificates or certification authorities.
The mechanisms by which authentication and authorization are performed.
The schema and type system for identity information.

Internet Drafts

The Working Group anticipates the authoring of at least three  
Internet Drafts, two of which are expected to be Standards Track  
documents.

DIX Use Cases – A catalogue of DIX protocol use cases to illustrate  
the problem being solved and to inform the decision making of the  
Working group. For example, an illustrative use case would be a  
website that accepts user generated content. A significant problem  
exists today that these sites attract the attention of spammers. The  
DIX protocol would allow that website to determine the identity of  
the submitter. A potential solution to the spam problem would be for  
the website to check that the submitter is of good standing in their  
community. In other words, the website would request the reputation  
of the submitter. The DIX protocol would allow that reputation data  
to be built up, aggregated, and moved between around.

DIX Protocol – A description of the DIX protocol.

DIX HTTP Transport Binding – How the DIX protocol will be mapped down  
onto HTTP as a transport layer. In this case the user’s software is a  
HTTP client, to which no modifications should be required, and the  
relying party would be a HTTP server. Continuing with the theme of  
simplicity a HTTP server should require minimal changes to support  
identity information exchange. For example, a HTML form could receive  
information the same way that a user would provide it, as if they  
typed it into the form themselves.

Goals and Milestones:

March 2006 – BOF meeting
April 2006 – DIX Use Cases Internet Draft
June 2006 – First DIX Protocol Internet Draft
June 2006 – First DIX HTTP Transport Binding Internet Draft
July 2006 – Working Group meeting
November 2006 – Working Group meeting
December 2006 – Request Last Call for DIX Protocol
December 2006 – Request Last Call for DIX HTTP Transport Binding
March 2007 – Working Group meeting
April 2007 – Submit DIX Protocol to IESG for consideration as  
Proposed Standard
April 2007 – Submit DIX HTTP Transport Binding to IESG for  
consideration as Proposed Standard

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

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Thu, 19 Jan 2006 14:25:49 -0800

> minimal modifications should be required to the user's software and  
> the relying party's software to participate in an identity  
> information exchange.

Suggested Change: The protocol should be both simple to implement and
secure.

> not limited to: HTTP, SOAP, XMPP, and SIP.

Not to quibble but I don't consider SOAP to be a transport protocol but a
messaging protocol. OTOH I could see SOAP, as a message envelope format, to
be used within one of the mentioned transport protocols.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John
Merrells
Sent: Thursday, January 19, 2006 12:46 PM
To: Digital Identity Exchange
Subject: [dix] draft of proposed charter (#2) 

John

----

Chairs

TBD

Mailing Lists:

Problem Statement

Goal

The goal of this group is to specify a protocol for moving identity  
information between parties and a system architecture that enables  
the development of software agents to manage the exchange of a user's  
identity information.

Method

An identity information exchange should involve just three parties:  
the user, their agent, and a relying party. The user's agent is where  
they authenticate themselves and a repository where they store their  
identity information, and the relying party is an entity requesting  
identity information.

The protocol should be both simple and secure. Simple meaning that  
minimal modifications should be required to the user's software and  
the relying party's software to participate in an identity  
information exchange. The protocol should be inherently scalable,  
requiring no centralized services, beyond those that already exist,  
in order to operate.

The security of a protocol is well understood within the IETF to be  
the assurance of confidentiality and integrity of any transferred  
information. But, in the context of digital identity we wish to also  
be assured that user's agents and relying parties maintain user privacy.

separation between the identifier and the user's agent. In the  

Work In Scope

Out of Scope

Internet Drafts

DIX Use Cases - A catalogue of DIX protocol use cases to illustrate  

DIX Protocol - A description of the DIX protocol.

DIX HTTP Transport Binding - How the DIX protocol will be mapped down  
onto HTTP as a transport layer. In this case the user's software is a  
HTTP client, to which no modifications should be required, and the  
relying party would be a HTTP server. Continuing with the theme of  
simplicity a HTTP server should require minimal changes to support  
identity information exchange. For example, a HTML form could receive  
information the same way that a user would provide it, as if they  
typed it into the form themselves.

Goals and Milestones:

March 2006 - BOF meeting
April 2006 - DIX Use Cases Internet Draft
June 2006 - First DIX Protocol Internet Draft
June 2006 - First DIX HTTP Transport Binding Internet Draft
July 2006 - Working Group meeting
November 2006 - Working Group meeting
December 2006 - Request Last Call for DIX Protocol
December 2006 - Request Last Call for DIX HTTP Transport Binding
March 2007 - Working Group meeting
April 2007 - Submit DIX Protocol to IESG for consideration as  
Proposed Standard
April 2007 - Submit DIX HTTP Transport Binding to IESG for  
consideration as Proposed Standard

---

From: John Merrells <[email-masked]>
Date: Thu, 19 Jan 2006 17:27:22 -0800

> Suggested Change: The protocol should be both simple to implement and

Doesn't the following sentence mean 'simple to implement' though?
And so change that to....

'Simple to implement' meaning that minimal modifications should be  
required to the user's software and the relying party's software to  
participate in an identity information exchange.

John

---

From: John Merrells <[email-masked]>
Date: Thu, 19 Jan 2006 17:28:54 -0800

> be used within one of the mentioned transport protocols.

How about...

"Any solution should support multiple transport and messaging  
protocols, including but not limited to: HTTP, SOAP, XMPP, and SIP. "

...?

John

---

From: John Merrells <[email-masked]>
Date: Thu, 19 Jan 2006 17:37:57 -0800

> participate in an identity information exchange.

(replying to my own post - sigh how sad)

Making it scan...

"Simple in terms of implementation in that minimal modifications  
should be required to the user's software and the relying party's  
software to participate in an identity information exchange."

John

---

From: David Boreham <[email-masked]>
Date: Thu, 19 Jan 2006 19:09:03 -0700

> protocols, including but not limited to: HTTP, SOAP, XMPP, and SIP. "

I've been wondering about the semantics behind this thread.
To me, this means things like 'I want my SIP phone to party with this
new widely deployed identidy framework'. Is that the same as
'support SIP as a transport' ? I'm not sure, since for example you
might want to use existing protocol already used in SIP for
authentication, but have the PBX (or whatever is being the SIP gateway)
use DIX. In that case the PBX would use HTTP transport,
wouldn't it ?

Put another way, is this statement above the same as saying
'support user agents or clients using multiple ... protocols... ' ?

---

From: John Merrells <[email-masked]>
Date: Thu, 19 Jan 2006 18:38:56 -0800

> use DIX. In that case the PBX would use HTTP transport,

Good question. I didn't bring up SIP as a transport myself, but
to me this means that I might want to send DIX messages over
SIP. Why would I do that... we'd need a use case... not really
knowing anything about SIP i'm not very well qualified to say
... but I might be on a call to a call center and they ask me to
prove something about me... right now they ask a bunch of
questions... SSN, MMN, DOB... with DIX over SIP they might
be able to send the request to my client and assuming it
had the appropriate interface (ie capabilities) it could ask
me if i wanted to reveal that identity information... i'd click
yes and it'd be revealed. Which sounds quite nice to me.

> 'support user agents or clients using multiple ... protocols... ' ?

It's a given to me that any agent or client could implement
any protocols it wanted to.... so i'm not trying to say that.

John

---

From: John Merrells <[email-masked]>
Date: Thu, 19 Jan 2006 18:43:06 -0800

>> protocols, including but not limited to: HTTP, SOAP, XMPP, and SIP. "

"Any solution should allow DIX messages to be carried over multiple  
alternative transport and messaging protocols, including, but not  
limited to: HTTP, SOAP, XMPP, and SIP. It is anticipated that this  
working group will initially focus on a HTTP based solution."

Hmm, almost as much weaseling as a legal document.

John

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Thu, 19 Jan 2006 18:47:37 -0800

> new widely deployed identidy framework'.

It could mean that your SIP phone authenticates itself before registering
with a SIP proxy or making a call. The proxy could then verify such claims
via the identity framework before making the connection. Or you could choose
two-levels of authentication - but that kind of defeats the purpose of
decoupling identity from services.

> Is that the same as 'support SIP as a transport'?

In the scenario above SIP could be used as the transport for the identity
transactions.

> I'm not sure, since for example you might want to use existing protocol
> already used in SIP for authentication, but have the PBX (or whatever is
> being the SIP gateway) use DIX.

The same argument can be made for HTTP as with SIP, after all the
authentication headers are the same. The SIP RFC leverages the HTTP/1.1
specification for syntax and semantics (WWW-Authenticate,
Proxy-Authenticate, etc.). You're arguing in terms of the PSTN world and the
current implementations of SIP that facilitate VoIP within those boundaries.
There's certainly no limitation in the RFC for the scenario above.

> 'support user agents or clients using multiple ... protocols... ' ?

The point is not to the limit the types of UA's that support DIX based on
the transport protocol. Every protocol binding is optional in the end.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David
Boreham
Sent: Thursday, January 19, 2006 6:09 PM
To: Digital Identity Exchange
Subject: Re: [dix] draft of proposed charter (#2)

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 19 Jan 2006 21:49:15 -0500

> From: John Merrells [mailto:[email-masked]] 
> Sent: Thursday, January 19, 2006 9:43 PM
> To: [email-masked]; Digital Identity Exchange
> "Any solution should allow DIX messages to be carried over 
> multiple alternative transport and messaging protocols, 
> including, but not limited to: HTTP, SOAP, XMPP, and SIP. It 
> is anticipated that this working group will initially focus 
> on a HTTP based solution."
> 

John, I would suggest that your charter should describe a need to specify at
least one "mandatory to implement" transport/messaging protocol to ensure a
minimal level of interoperability.  I don't care if you use weasel words now
to avoid picking one at charter time, but you should commit to settling on
one.

-Scott-

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Thu, 19 Jan 2006 18:59:50 -0800

> John, I would suggest that your charter should describe a need to specify
> at least one "mandatory to implement" transport/messaging protocol to
> ensure a minimal level of interoperability.  I don't care if you use
> weasel words now to avoid picking one at charter time, but you should
> commit to settling on one.

I agree and disagree - the core of DIX will be transport independent. The
only spec'd binding in the charter is for HTTP, therefore there is a
"minimal level of interoperability" for the first set of implementations by
virtue of having only one spec'd binding. After that there will be specs for
other bindings and there's no reason why different identity realms can't
implement their own bindings or all the bindings (HTTP - Web Apps, SIP -
VoIP, XMPP - IM, etc,).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott
Hollenbeck
Sent: Thursday, January 19, 2006 6:49 PM
To: 'Digital Identity Exchange'
Subject: RE: [dix] draft of proposed charter (#2)

-Scott-

---

From: John Merrells <[email-masked]>
Date: Thu, 19 Jan 2006 19:10:03 -0800

> implement their own bindings or all the bindings (HTTP - Web Apps,  

I think Scott's point is that we mandate that the parties must  
implement one
particular binding. I'm uneasy about this because there may be use cases
where it doesn't make sense. There's two pieces to the protocol.

agent to user - DIX over X

user to relying party - DIX over Y

In the internet phone use case we we're just talking about, X could be
HTTP and Y could be SIP. So we can't really mandate that all three
parties implement either HTTP or SIP.

Hmm...

John

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Thu, 19 Jan 2006 19:33:43 -0800

> implement one particular binding.

That's the part I was disagreeing with. I was just trying to pointing out
that the first spec'd binding, HTTP, would allow for DIX to build traction
and that we did not need to have a "mandatory" binding.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John
Merrells
Sent: Thursday, January 19, 2006 7:10 PM
To: Digital Identity Exchange
Subject: Re: [dix] draft of proposed charter (#2)

Hmm...

John

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Fri, 20 Jan 2006 07:12:37 -0500

> From: Suresh Venkatraman [mailto:[email-masked]] 
> Sent: Thursday, January 19, 2006 10:34 PM

What's the difference between "first spec'd binding" as you used those words
above and "mandatory" as I described?  My point is that a working group is
going to have to craft a spec that allows two implementations to
interoperate.  If someone implements something using http, and someone else
does something different (and the specs allow both) such that they don't
interoperate, then there is going to be a problem.  The foundation that
allows interoperability MUST be specified in the charter.

-Scott-

---

From: Peter Davis <[email-masked]>
Date: Fri, 20 Jan 2006 09:46:56 -0500

> yes and it'd be revealed. Which sounds quite nice to me.

SIP presently has means to 'prove' the identity of the calling party
sip-identity [1] which supplies a new header (and some hash/signing). While
it is presently in ID, it is header to RFC editor queue.

It would be for the SIP WG to draft a binding of 'dix' with sip-identity,
IMHO. At least for the purposes laid out in the above use case.

=peterd  (http://public.xdi.org/=peterd)

[1] http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-06.txt

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 20 Jan 2006 09:27:02 -0700

John Merrells wrote:
> "Any solution should support multiple transport and messaging protocols, 
> including but not limited to: HTTP, SOAP, XMPP, and SIP. "

I think Suresh's point was that SOAP is not a transport or messaging 
protocol, but a message format that can be carried over such protocols. 
E.g., there are (AFAIK) four transport/messaging bindings for SOAP: 
HTTP, SMTP, BEEP, and XMPP.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml
_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Fri, 20 Jan 2006 09:32:35 -0800

> What's the difference between "first spec'd binding" as you used those
> words above and "mandatory" as I described?  My point is that a working
> group is going to have to craft a spec that allows two implementations to
> interoperate.  If someone implements something using http, and someone
> else does something different (and the specs allow both) such that they
> don't interoperate, then there is going to be a problem.  The foundation
> that allows interoperability MUST be specified in the charter.

I'm arguing that the foundation for interoperation is the DIX protocol and
not the binding to a specific transport protocol (HTTP). By making a
particular binding "mandatory" for all implementations, you are potentially
limiting future choices. For instance, would I be forced to implement HTTP
in all XMPP and SIP clients and proxies even though XMPP and SIP bindings
may exist? And that begs the question - why HTTP?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott
Hollenbeck
Sent: Friday, January 20, 2006 4:13 AM
To: 'Digital Identity Exchange'
Subject: RE: [dix] draft of proposed charter (#2)

-Scott-

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Fri, 20 Jan 2006 09:39:55 -0800

> HTTP, SMTP, BEEP, and XMPP.

Yes, that was my point. It's a bit tricky since in RFC 3288, SOAP is
mentioned as a XML-based messaging protocol.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter
Saint-Andre
Sent: Friday, January 20, 2006 8:27 AM
To: Digital Identity Exchange
Subject: Re: [dix] draft of proposed charter (#2)

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 20 Jan 2006 10:48:07 -0700

> mentioned as a XML-based messaging protocol.

That text is still in RFC 4227 but I think we should depend on the SOAP 
specs to correctly characterize what SOAP is.

Peter

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Fri, 20 Jan 2006 13:27:16 -0500

> Sent: Friday, January 20, 2006 12:33 PM

OK, I agree with the "why HTTP" question.  That's one you guys need to
figure out.  I'm telling you now, though, that a charter that does not
describe at least one method to produce interoperable implementations will
not be approved by the IESG.

-Scott-

---

From: Peter Davis <[email-masked]>
Date: Fri, 20 Jan 2006 13:40:06 -0500

> not be approved by the IESG.

If you really want this to be a compossible identity framework, than perhaps
the path sought is really 2 drafts. One for the core specification, the
other for the particular transport binding the wg feels is most likely to
see adoption  (or has unfulfilled requirements), which may be HTTP .  It
also allows other specs to incorporate nicely into some new transport.

---

From: John Merrells <[email-masked]>
Date: Fri, 20 Jan 2006 11:46:58 -0800

> it is presently in ID, it is header to RFC editor queue.

Hey.... you sniped off my caveat... 'not really knowing anything
about SIP i'm not very well qualified to say...', pout ;-)

> IMHO. At least for the purposes laid out in the above use case.

Yep. Transport bindings should be done in the WG that makes
most sense for that transport. Some WGs have wound down
of course, which would mean doing them in DIX, or spinning
up a new group.

John

---

From: John Merrells <[email-masked]>
Date: Fri, 20 Jan 2006 11:49:51 -0800

> allows interoperability MUST be specified in the charter.

I understand your point and am working on addressing it.

John

---

From: John Merrells <[email-masked]>
Date: Fri, 20 Jan 2006 11:54:37 -0800

On 20-Jan-06, at 9:48 AM, Peter Saint-Andre wrote:

>>> I think Suresh's point was that SOAP is not a transport or  
>>> messaging protocol, but a message format that can be carried over  
>>> such protocols.
>>> E.g., there are (AFAIK) four transport/messaging bindings for  
>>> SOAP: HTTP, SMTP, BEEP, and XMPP.
> That text is still in RFC 4227 but I think we should depend on the  
> SOAP specs to correctly characterize what SOAP is.

How about...

'messaging formats and transports'

"Any solution should allow DIX messages to be carried over multiple  
alternative messaging formats and transports, including, but not  
limited to: HTTP, SOAP, XMPP, and SIP. It is anticipated that this  
working group will initially focus on a HTTP based solution."

John

---

From: John Merrells <[email-masked]>
Date: Fri, 20 Jan 2006 12:01:48 -0800

> also allows other specs to incorporate nicely into some new transport.

That's the approach the charter is taking at the moment.
In draft #2 I called out the expected documents that would
come out of a WG and they're in the milestone section.
Is the text not clear on that?

John

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 20 Jan 2006 13:47:22 -0700

John Merrells wrote:
> alternative messaging formats and transports, including, but not limited 
> to: HTTP, SOAP, XMPP, and SIP. It is anticipated that this working group 
> will initially focus on a HTTP based solution."

I suggest leaving SOAP out of it. In what way will SOAP be a carrier for 
digital identity exchange? If SOAP will be an encapsulating format for 
digital identity data, then it will be transported using one of the SOAP 
bindings (HTTP, SMTP, BEEP, XMPP). But the same could be said of methods 
for encapsulating digital identity data in SAML, XHTML, Atom, or 
whatever else people dream up as a wrapper.

Peter

---

From: John Merrells <[email-masked]>
Date: Fri, 20 Jan 2006 13:15:52 -0800

On 20-Jan-06, at 12:47 PM, Peter Saint-Andre wrote:

> I suggest leaving SOAP out of it. In what way will SOAP be a  
> carrier for digital identity exchange? If SOAP will be an  
> encapsulating format for digital identity data, then it will be  
> transported using one of the SOAP bindings (HTTP, SMTP, BEEP,  
> XMPP). But the same could be said of methods for encapsulating  
> digital identity data in SAML, XHTML, Atom, or whatever else people  
> dream up as a wrapper.

Yes, very good point....

John

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Fri, 20 Jan 2006 16:45:21 -0800

> SIP presently has means to 'prove' the identity of the calling party sip
> identity [1] which supplies a new header (and some hash/signing). While it
> is presently in ID, it is header to RFC editor queue.
>

It's in the draft "Enhancements for Authenticated Identity Management in the
Session Initiation Protocol (SIP)". It assumes identity is defined for SIP,
but is not cryptographically secure. From the draft:

   "The existing security mechanisms in the Session Initiation Protocol
   are inadequate for cryptographically assuring the identity of the end
   users that originate SIP requests, especially in an interdomain
   context."

   "An identity, for the purposes of this document, is defined as a SIP URI,
   commonly a canonical address-of-record (AoR) employed to reach a user
   (such as 'sip:[email-masked]')."

   "This document defines a new role for SIP entities called an
   authentication service."

The draft is of course motivated by a need for authenticating identity but I
worry about yet another separate but incompatible scheme for SIP. There is
also a proposal to bind SAML to SIP titled "Using SAML for SIP". 

And from the SIP charter
(http://www.ietf.org/html.charters/sip-charter.html):

	In addition to extending SIP as required to address these
externally-
	derived requirements, the deliverables of the group include assuring
	capable security and privacy mechanisms within SIP and increasing
	the stability of the SIP specification.

	Specific deliverables toward these goals include:

	1. Mechanisms for secure expression of identity in requests and
	   responses.

	3. Guidelines for use of existing security mechanisms such as TLS,
	   IPsec, and certificates.

	4. Guidelines for the use of descriptive techniques such as SAML
	   (Security Association Markup Language) with SIP.

Some future DIX binding for SIP will help add to the confusion.

<sarcasm>
Of course it's par for the course to throw everything under the sun into
SIP. And the charter actually states simplicity as its goal... I can't wait
until every application or network WG has its own version of identity, none
of which will interoperate.
</sarcasm>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter
Davis
Sent: Friday, January 20, 2006 6:47 AM
To: Digital Identity Exchange; [email-masked]
Subject: Re: [dix] draft of proposed charter (#2)

---

From: John Merrells <[email-masked]>
Date: Fri, 20 Jan 2006 19:16:40 -0800

> not be approved by the IESG.

I've been chewing this over all day:

We can't mandate that the other party in the exchange implement
DIX over a particular transport. It's an implementation decision
between the user's client and the other party. We have the motivating
use cases of a VOIP phone or IM client to illustrate this.

We could mandate the transport between the user's client and their
agent. HTTP perhaps... given its simplicity and ubiquity. I do hesitate
though, because I'm sure there are use cases where that doesn't
make sense. For example my agent might actually be built into my
client so the transport is IPC or API. What use would that kind of
agent be?... well it could just be a local replica of my agent in the
internet. Hmm, is my local agent really just an agent of my agent
and therefore a non-principal party to the exchange. Agh. What if
my agent were on a USB key or a smart card? What would my
transport be then... I'm not sure... I suppose it could be HTTP...

We could state:

"To ensure interoperability between implementations we mandate
that the user's client and their agent must support at least DIX
over HTTP."

It's hard to be definitive about this without the use cases to refer
to...

I'd appreciate any comments you folk on the list have about this.

John

---

From: Pete Rowley <[email-masked]>
Date: Fri, 20 Jan 2006 19:33:50 -0800

> We can't mandate that the other party in the exchange implement

Isn't the point of issue here that there needs to be documented a way to 
(stealing the words) "produce interoperable  implementations" so that it 
can be shown that it _works_ by having "interoperable  implementations" 
- this isn't a question of mandating anything, but codifying how using 
the protocol over one method of transport would work.

> that the user's client and their agent must support at least DIX
So rather than this, a document describing the protocol over, say, HTTP 
would be a deliverable.

-- 
Pete

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Fri, 20 Jan 2006 21:08:05 -0800

> So rather than this, a document describing the protocol over, say, HTTP

Actually, this was already part of both proposals:

   Goals and Milestones:

   April 2007 - Submit DIX Protocol to IESG for consideration as Proposed
                Standard
   April 2007 - Submit DIX HTTP Transport Binding to IESG for consideration
                as Proposed Standard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pete
Rowley
Sent: Friday, January 20, 2006 7:34 PM
To: Digital Identity Exchange
Subject: Re: [dix] draft of proposed charter (#2)

-- 
Pete

---

From: John Merrells <[email-masked]>
Date: Sat, 21 Jan 2006 00:20:46 -0800

On 20-Jan-06, at 7:33 PM, Pete Rowley wrote:

> Isn't the point of issue here that there needs to be documented a  
> way to (stealing the words) "produce interoperable   
> implementations" so that it can be shown that it _works_ by having  
> "interoperable  implementations" - this isn't a question of  
> mandating anything, but codifying how using the protocol over one  
> method of transport would work.

Nope...

Here's an illustration of the issue...

Usually in a protocol definition there are only two parties, the client
and the server. If some aspect of the protocol was optional say A
or B then someone could implement a client that did A and someone
else could produce a server that talked B. Compliant implementations
but not interoperable. The solution is to mandate A and make B
optional.

But, we have a different situation. Three parties and two exchanges...

Given parties A, B, and C where separate protocol exchanges can
occur between parties A and B, and between parties B and C...

I just don't think that every B has to be able to talk to every A and
be able to talk to every C.

This is probably easiest to state in first order predicate logic...

Given parties A, B, and C where separate protocol exchanges can
occur between parties A and B, and between parties B and C; it
must hold that a single instance of a transitive relationship must exist
between every A and some C through some B, and it must also
hold that there is a reverse transitive relationship instance from
every C to some A through some B, and that every B participates
in one of those relationships... ohhh... that's a transitive closure.
In other words: the transitive closure of all As includes all Cs
through all Bs. Hence it matters not what the transport actually is,
just that this constraint holds.

I think that's a good argument against mandating a transport.

What needs to be mandated to ensure interoperation is that...

An A must be able to talk to a B.
A B must be able to talk to an A and a C.
A C must be able to talk to a B.

I'll see about working that into charter style text tomorrow.

John

---

From: Joaquin Miller <[email-masked]>
Date: Sun, 22 Jan 2006 15:58:31 -0800

Very well put, John!  This is the kind of thinking we need.  And the 
kind of clear explication of the thinking that is essential for good progress.

Cordially, Joaquin

---

From: John Merrells <[email-masked]>
Date: Sun, 22 Jan 2006 20:02:38 -0800

On 22-Jan-06, at 3:58 PM, Joaquin Miller wrote:

> Very well put, John!  This is the kind of thinking we need.  And  
> the kind of clear explication of the thinking that is essential for  
> good progress.

Thanks <blush>, but I can't take all the credit, as I had help from
my friend Mr. Cabernet Sauvignon.

This evening's email lubricant is the cheeky little Ms. Merlot.

Mmm, nice.

John

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 23 Jan 2006 12:00:02 -0800

This email is getting closer to picking apart the different pieces of  
the network architecture for delegated authority and considering  
those pieces separately with respect to Scott's suggestion of certain  
"required to implement" transports.  I think we need to take it  
further because each main line in the network diagram has to be  
considered separately.

I'm going to use my own terms for the 3 parties here because my  
confusion about the official terms is an appropriate subject for a  
different mail but I can't quite bring myself to use them.  Thus, my  
simplified network diagram which ignores proxies and optional bits  
like talking to directories

   Content
   Server---------|
     |            |
     |          Identity
     |          Server
     |            |
   Client---------|

> use cases of a VOIP phone or IM client to illustrate this.

Here you're talking about the communication between the client and  
the content server in my diagram.  That communication is almost  
outside the scope of DIX.  It's the communication that already takes  
place over many, many protocols, not all of which DIX WG can tackle.   
My personal suggestion is that DIX should tackle HTTP and add a new  
Authorization header type and WWW-Authenticate capability token and  
associated parameters, and perhaps also tackle SASL for which I'm not  
qualified to suggest how.

> transport be then... I'm not sure... I suppose it could be HTTP...

Now you're talking about the communication between client and  
identity server in my diagram.  The identity server MUST support one  
or more well-known protocols such that if I'm implementing a client,  
I can count on being able to contact a standards-compliant identity  
server if I'm willing to do the work.  Of course a client might go  
beyond that and implement other protocols to talk to the identity  
server -- even proprietary protocols -- but that would have to rely  
on capability discovery or provisioning in order to work.

So let's say DIX required BEEP and HTTP (at random) as the REQUIRED  
TO IMPLEMENT transports for a compliant identity server.  This  
doesn't necessarily solve all problems for all clients but it does  
make it clear what the client implementor has to do.

> that the user's client and their agent must support at least DIX

Yes, but even more important for the identity server to have required- 
to-implement transports.

> It's hard to be definitive about this without the use cases to refer

I may be assuming the use cases, but I'll forge onward.

The last major line in the network diagram is the communication  
between the identity server and the content server.  Over this link,  
REQUIRED transports are crucial and can be kept, I suspect, to just  
one.  All content servers that advertise support for DIX delegated  
authorization MUST be able to communicate with the identity server  
chosen by the client using this one transport.  All identity servers  
that advertise compliance with DIX MUST be able to communicate with  
the content server chosen by the client using this one transport.

A single mandatory transport is most crucial for this link because  
both the content server and identity server are chosen by the client  
or user, and the two servers commonly have no ability or opportunity  
to do any provisioning or setup, and can only negotiate over the wire  
after initially making some kind of blind connection in one of the  
two directions.

Revisiting my simplistic network diagram:

      Content
      Server---------| = ONE TRANSPORT
        |            |
  ANY = |          Identity
        |          Server
        |            |
      Client---------| = ONE/TWO TRANSPORTS or configure/provision  
otherwise

Lisa

---

From: John Merrells <[email-masked]>
Date: Mon, 23 Jan 2006 14:02:05 -0800

On 23-Jan-06, at 12:00 PM, Lisa Dusseault wrote:

> different mail but I can't quite bring myself to use them.

Yes, I'm not too fond of the 'identity gang' names.

> Thus, my simplified network diagram which ignores proxies and  
> optional bits like talking to directories
>
>   Content
>   Server---------|
>     |            |
>     |          Identity
>     |          Server
>     |            |
>   Client---------|

OK

> outside the scope of DIX.  It's the communication that already  
> takes place over many, many protocols, not all of which DIX WG can  
> tackle.

Indeed.

> My personal suggestion is that DIX should tackle HTTP

That's my preference, but I wanted to leave the option open in case  
others wanted to tackle other protocols within this WG.

> and add a new Authorization header type and WWW-Authenticate  
> capability token and associated parameters,

That'd sounds like a good way to do it.

> and perhaps also tackle SASL for which I'm not qualified to suggest  
> how.

Me neither.

> identity server in my diagram.  The identity server MUST support  
> one or more well-known protocols such that if I'm implementing a  
> client, I can count on being able to contact a standards-compliant  
> identity server if I'm willing to do the work.  Of course a client  
> might go beyond that and implement other protocols to talk to the  
> identity server -- even proprietary protocols -- but that would  
> have to rely on capability discovery or provisioning in order to work.

Yes.

> make it clear what the client implementor has to do.

Does a client have to be able to talk to every identity server in
existence though. Maybe, but I'm not sure... that's what motivated
me to start on the use cases. If I'm worrying for no reason then
I'd be OK with mandating one transport for identity providers
and clients.

> Yes, but even more important for the identity server to have  
> required-to-implement transports.

My terms confused you. The agent is the identity server, so I'm  
saying the same thing there.

> between the identity server and the content server.  Over this  
> link, REQUIRED transports are crucial and can be kept, I suspect,  
> to just one.  All content servers that advertise support for DIX  
> delegated authorization MUST be able to communicate with the  
> identity server chosen by the client using this one transport.  All  
> identity servers that advertise compliance with DIX MUST be able to  
> communicate with the content server chosen by the client using this  
> one transport.
>
> both the content server and identity server are chosen by the  
> client or user, and the two servers commonly have no ability or  
> opportunity to do any provisioning or setup, and can only negotiate  
> over the wire after initially making some kind of blind connection  
> in one of the two directions.
>

Yes - good point.

I didn't include the protocol exchange between the content server and  
the identity
server because I though there might be alternative solutions that  
didn't involve a
direct connection. dmd1 does this to minimize the code and its  
complexity at the
content server (it's some message handling and a hash function). But  
an alternative
solution could do something more sophisticated.

I had a private email from somebody who took much the same position.

Does anyone else want to pitch in an opinion on this?

John

---

From: Peter Davis <[email-masked]>
Date: Tue, 24 Jan 2006 09:19:37 -0500

On 1/20/2006 3:01 PM, "John Merrells" <[email-masked]> wrote:

>> 2 drafts. One for the core specification,  the
>> other for the particular transport binding the wg feels is most
>> likely to see adoption  (or has unfulfilled requirements), which may be
>> HTTP 
 
> Is the text not clear on that?

More likely a case of the aging eyes ;-)
2 drafts +1

=peterd

---

From: Peter Davis <[email-masked]>
Date: Tue, 24 Jan 2006 09:37:35 -0500

On 1/20/2006 7:45 PM, "Suresh Venkatraman" <[email-masked]> wrote:

> but is not cryptographically secure.

Which is true.  SIP (without mechanisms such as SIP-identity) suffer the
same authentication problems email does. Specifically, the ability for the
UAC to forge the 'From' header.

> also a proposal to bind SAML to SIP titled "Using SAML for SIP".

I am not suggesting a new scheme for SIP, others were suggesting SIP as
another target transport.  SIP-identity/SIP-SAML are there now.  As I
stated, it would be up to the SIP WG to determine if adding a 'dix'
mechanism is a 'Good Thing' or not.

> Some future DIX binding for SIP will help add to the confusion.

Yep. So we leave it up to them.

> of which will interoperate.

;-)

=peterd

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Tue, 24 Jan 2006 09:33:43 -0800

>> It's in the draft "Enhancements for Authenticated Identity Management in
>> the Session Initiation Protocol (SIP)". It assumes identity is defined
>> for SIP, but is not cryptographically secure.
>

SIP does not necessarily suffer from those problems, and the spec
acknowledges this. Existing challenge/response mechanisms using digest could
solve this problem given a well known SIP server for the UAC (SRV perhaps)
w/ Certs. The spec acknowledges that other mechanisms exist but goes on to
state lack of support from user-agents. IMO, lack of support is not a good
reason to create another way of doing the same thing.

>From the Spec:

	RFC3261 specifies a number of security mechanisms that can be
employed
	by SIP UAs, including Digest, TLS and S/MIME (implementations may
	support other security schemes as well). However, few SIP user
agents
	today support the end-user certificates necessary to authenticate
	themselves

> mechanism is a 'Good Thing' or not.

The same can be said of any chosen transport protocol including HTTP. Are
you suggesting that every protocol binding should be done by the existing
working group? IMO, unless the DIX transport binding extends the particular
transport protocol, it should be done by this group. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter
Davis
Sent: Tuesday, January 24, 2006 6:38 AM
To: Digital Identity Exchange <[email-masked]>
Subject: Re: [dix] draft of proposed charter (#2)

;-)

=peterd

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 24 Jan 2006 11:40:04 -0700

I'm likely tainting this with my own views , but it feels like what most
people want is a protocol definition which at some level is transport
independent. On top of that, bindings to HTTP would be defined. The HTTP
bindings would be seen as the easiest route to interoperability.
Bindings to other transports may be defined, but don't have to be within
the charter of the DIX WG. Depending on how much work is involved in
writing a binding spec, some kind of guidelines document for doing so
might be necessary.
 
How tightly coupled the transport-independent parts and HTTP-specific
are defined to be is debatable. The more loosely coupled, the more
re-work to dmd-01.
 
Is this a fair general read?
 
Jim

>>> [email-masked] 1/24/06 10:33:43 am >>>

SIP does not necessarily suffer from those problems, and the spec
acknowledges this. Existing challenge/response mechanisms using digest
could
solve this problem given a well known SIP server for the UAC (SRV
perhaps)
w/ Certs. The spec acknowledges that other mechanisms exist but goes on
to
state lack of support from user-agents. IMO, lack of support is not a
good
reason to create another way of doing the same thing.

> mechanism is a 'Good Thing' or not.

The same can be said of any chosen transport protocol including HTTP.
Are
you suggesting that every protocol binding should be done by the
existing
working group? IMO, unless the DIX transport binding extends the
particular
transport protocol, it should be done by this group. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter
Davis
Sent: Tuesday, January 24, 2006 6:38 AM
To: Digital Identity Exchange <[email-masked]>
Subject: Re: [dix] draft of proposed charter (#2)

>> SIP presently has means to 'prove' the identity of the calling party
sip
>> identity [1] which supplies a new header (and some hash/signing).
While
it
> It's in the draft "Enhancements for Authenticated Identity Management
in
the
> Session Initiation Protocol (SIP)". It assumes identity is defined
for
SIP,
> but is not cryptographically secure.

Which is true.  SIP (without mechanisms such as SIP-identity) suffer
the
same authentication problems email does. Specifically, the ability for
the
UAC to forge the 'From' header.

> 
> The draft is of course motivated by a need for authenticating
identity but
I
> also a proposal to bind SAML to SIP titled "Using SAML for SIP".

I am not suggesting a new scheme for SIP, others were suggesting SIP
as
another target transport.  SIP-identity/SIP-SAML are there now.  As I
stated, it would be up to the SIP WG to determine if adding a 'dix'
mechanism is a 'Good Thing' or not.

> SIP. And the charter actually states simplicity as its goal... I
can't
wait
> until every application or network WG has its own version of
identity,
none

;-)

=peterd

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Tue, 24 Jan 2006 10:52:06 -0800

> bindings would be seen as the easiest route to interoperability. Bindings
> to other transports may be defined, but don't have to be within the
> charter of the DIX WG. Depending on how much work is involved in writing a
> binding spec, some kind of guidelines document for doing so might be
> necessary.
> ...

I would be in agreement with this approach as it allows for immediate
interoperability (HTTP) while maintaining flexibility in future binding
implementations.

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim
Sermersheim
Sent: Tuesday, January 24, 2006 10:40 AM
To: 'Digital Identity Exchange'
Subject: Transports (was: RE: [dix] draft of proposed charter (#2)_

I'm likely tainting this with my own views , but it feels like what most
people want is a protocol definition which at some level is transport
independent. On top of that, bindings to HTTP would be defined. The HTTP
bindings would be seen as the easiest route to interoperability. Bindings to
other transports may be defined, but don't have to be within the charter of
the DIX WG. Depending on how much work is involved in writing a binding
spec, some kind of guidelines document for doing so might be necessary.
 
How tightly coupled the transport-independent parts and HTTP-specific are
defined to be is debatable. The more loosely coupled, the more re-work to
dmd-01.

Jim

-----Original Message-----

the

;-)

=peterd

---

From: Ben Laurie <[email-masked]>
Date: Thu, 26 Jan 2006 13:49:05 +0000

> required-to-implement transports.

Errr. The identity server in your diagram is the agent in the proposed
charter, surely?

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff