Subject: RE: [dix] Re: attribute assertions

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Jan 2006 18:48:55 -0800

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

> DNS SRV is specifically built for service discoverability, 
> like MX records are used to discover mail servers.

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

---

From: Dick Hardt <[email-masked]>
Date: Tue, 17 Jan 2006 18:59:10 -0800

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

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Tue, 17 Jan 2006 20:04:14 -0800

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

Good point.

---

From: John Merrells <[email-masked]>
Date: Wed, 18 Jan 2006 15:09:24 -0800

> say are or are not part of DIX? Off the top of my head and in no  

I'll have a crack at this. Would be interested to hear what others  
think.

> * Location Discovery (of the ID-Service)

In scope. In general a relying party can't do much without discovery in
the system somewhere.

In draft-merrells-dix-01 (dmd1) we just ask the user, and then  
optionally
cookie the user... so I think it can be done in a very simple way.

> * Validation (of the ID-Service)

I'm not sure what that means. Sounds a bit like trust. If so I think we
can make that out of scope as multiple trust models could be applied
and there are existing mechanisms for achieving that.

In dmd1 the membersite relies upon the user to trust their homesite.

> * Negotiation (Content, Encoding, Language, Security, Algorithms)

In scope.

In dmd1 was have 'capabilities', which are used to represent these
things and advertise them between membersites and homesites.

> * Common Identity Scheme (URI's, URL's, XRI's, etc.)

In scope.

In dmd1 we have the Persona URL as the identifier.

> * Identity Authentication (e.g. one-time passwords, digest, pki, etc.)

Out of scope for how authentication is done... but in scope for how
a membersite might require a certain level of authentication to be
performed

In dmd1 we don't specify any authentication mechanisms and we
have the capabilities for declaring how auth could be done... and
we have some thoughts around how a membersite could make
assertions about its requirements.

> * Identifier Exchange (Claims, Mappings, etc.) - Addressed in SAML?

I'm not sure what that is. How someone identifies themselves?
In that there's an assertion that they've authenticated as a
certain identifier.

In scope... but I'd generalize it to exchange of attributes and claims.

dmd1 has messages for fetching and storing 'properties'.

> * Bindings (HTTP, SMTP, SIP, etc.)

In scope.

dmd1 constrains itself to HTTP.

> * Security Layers - Compatible with by TLS, SASL, BEEP, etc.?

Um... In and Out of scope.

TLS - In, but I think that's an issue for the transport binding.

BEEP - In, but again that's a transport binding thing. I loved it.
After working on LDAP(S) IO code I really loved it.

SASL - Out... I think... last time I looked that was a framework/api
for dropping authentication mechanisms into... but I may not be
totally up to date on that. That's an identity authentication thing,
so out of scope from my point of view.

> * Federation (Unifying the Namespace)

Out of scope.

> folded into the DIX framework (when one exists).

Our general goal has been/should be to reuse as much as possible,
and add only what is necessary to meet the requirements...

> In addition has anyone

Bob had a stab at it on this list, but beyond that the use cases
are mostly being talked about in other communities. A draft
that documented the driving use cases would be a good thing,
but not essential if the community here believes there is a real
problem to solve and this is the way to solve it.

John

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Wed, 18 Jan 2006 17:39:45 -0800

> In dmd1 the membersite relies upon the user to trust their homesite.

The question was validation of the ID-server or "homesite" in DMD1
terminology; as in does DIX provide a mechanism to validate or assert that
the "homesite" is in fact who/what it says it is. This is probably outside
the scope of DIX and is better left to the TLS/SSL layer.

> assertions about its requirements.

Is there a specific reason why negotiating the authentication mechanism
should not be part of the protocol? Is it assumed that authentication will
be addressed in the particular binding (HTTP, etc.)? We wouldn't need to
make one up, just allow choice from the existing authentication schemes.

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

In scope.

In scope.

In scope.

Out of scope.

John

---

From: John Merrells <[email-masked]>
Date: Wed, 18 Jan 2006 18:08:25 -0800

> the scope of DIX and is better left to the TLS/SSL layer.

I think so.

In dmd1 we have message verification, which just checks that a msg
was sent from who says they sent them... which is no more secure
than DNS.

If you want assertions about the server identity then that's something
you could layer on top.

I think of that as 'Trust' though, maybe you don't.

> make one up, just allow choice from the existing authentication  

I think that it is part of the protocol. I'm saying that we don't define
any authentication mechanisms, but we do allow the parties to
say which they can do, and which they are willing to accept.

In dmd1 a HS advertises it's capabilities, which might include
the authentication mechanisms it supports, and a MS can
decide whether to accept assertions from that HS or not.

John

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Wed, 18 Jan 2006 19:16:39 -0800

> decide whether to accept assertions from that HS or not.

In DMD1 (Section 5.10.1.5) there is mention of an authentication requirement
scenario but it kind of leaves negotiation out of the discussion. Unless you
mean that member sites individually dictate authentication requirements
every time a fetch-request is made?

DMD1: dix://crypto-doodes.com/dongle#5

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

I think so.

John

---

From: John Merrells <[email-masked]>
Date: Wed, 18 Jan 2006 19:27:12 -0800

> DMD1: dix://crypto-doodes.com/dongle#5

Yes and No. Yes the Membersite does it, but No it's not per message.

It's per MS/HS relationship. When the MS discovers the HS capabilities
(by pulling the HS Document and looking for the Homesite Tag) it can
make a determination of whether the HS supports appropriate
authentication methods or not.

A per message solution is possible thus: In a fetch request the MS
requests a claim from the HS that the authentication was performed
using a particular method. DMD1 facilitates this, but doesn't define
what property the MS would ask for, or what the claim would actually
look like.

John