Subject: RE: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 25 Jan 2006 21:25:57 -0800

I think that there are two separate types of identity information that
need to be considered here:

1) Self asserted information (nickname, photo, email etc.)
2) Third party assertions (reputation, spamminess, star alliance gold
etc.)

The first type of information is not difficult to manage, the relying
party understands that the data is self asserted. Attribute value pairs
in any standard format work as well as anything.

The second type of information requires the reputation of the
information provider to be considered by the relying party. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Suresh Venkatraman
> Sent: Wednesday, January 25, 2006 3:59 PM
> To: 'Digital Identity Exchange'
> Subject: RE: of identifiers and identity service discovery 
> (was: Re: [dix]Toadd to the charter)
> 
> > So, yes, my point is that for whatever reason there is an extant 
> > plethora of identity-asserting protocols, and they aren't 
> simply going 
> > to dry up and blow away because this working group is formed, and 
> > perhaps re-invents another wheel.
> 
> In order for DIX to be approved by the IESG we need to choose 
> one of the identity-asserting protocols. That could mean a 
> subset of an existing standard (SAMLv2) or creating one that 
> can provide an "interoperable implementation". Emerging or 
> alternative protocols could be added in later.
> 
> > And as PHB noted earlier on this list, another high-level aspect of 
> > this overall identity puzzle is one of identifiers themselves.
> >
> > And even with identifiers themselves, there is a fair bit of extant 
> > non trivial emerging deployed work, which isn't necessarily 
> going to 
> > disappear right away. Eg XRIs [1][2].
> 
> IMO, leveraging existing identifiers (URI's, URL's, Mail 
> Addresses) and discovery mechanisms (DNS) are more 
> interesting than trying to reinvent the wheel. It's much 
> easier to codify DIX with well known and widely-used 
> identifiers. OTOH I would want DIX to keep the core spec open 
> for emerging or alternative identifiers (e.g. XRI's).
> 
> > So I tend to think that up-leveling the discussion to be 
> one focusing 
> > on a
> 
> > meta-layer framework for identifier resolution and identity service 
> > discovery (aka identity provider discovery) is where the 
> value for an 
> > IETF-based effort lies.
> 
> To quote Scott Hollenbeck: "A charter that does not describe 
> at least one method to produce interoperable implementations 
> will not be approved by the IESG."
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jeff Hodges
> Sent: Wednesday, January 25, 2006 10:45 AM
> To: Digital Identity Exchange
> Subject: of identifiers and identity service discovery (was: 
> Re: [dix] Toadd to the charter)
> 
> 
>  >> John Merrells had mused:
>  >>> I don't think that we need a protocol to interoperate 
> with other  >>> protocols. I think we need one protocol.
> 
>  > Jeff Hodges replied:
>  >> You're dreaming. Those horses are out of the barn and off 
> in the next  >> state.
> 
> Suresh Venkatraman opined:
>  > IMO, the horses are a bunch of disconnected islands spread 
> across the  > internet. It sure would be nice to have a 
> single system that wasn't  > controlled by one company to 
> connect the islands.
> 
> So, yes, my point is that for whatever reason there is an 
> extant plethora of
> 
> identity-asserting protocols, and they aren't simply going to 
> dry up and blow away because this working group is formed, 
> and perhaps re-invents another wheel.
> 
> I think where some value could be added is pretty much what 
> you're alluding to above which is specifying a standard means 
> by which one can determine which flavor of identity-asserting 
> system a given identifier is recognized by.
> 
> yadis.org is one such effort, fwiw.
> 
> And as PHB noted earlier on this list, another high-level 
> aspect of this overall identity puzzle is one of identifiers 
> themselves.
> 
> And even with identifiers themselves, there is a fair bit of 
> extant non-trivial emerging deployed work, which isn't 
> necessarily going to disappear right away. 
> Eg XRIs [1][2].
> 
> So I tend to think that up-leveling the discussion to be one 
> focusing on a meta-layer framework for identifier resolution 
> and identity service discovery (aka identity provider 
> discovery) is where the value for an IETF-based effort lies.
> 
> JeffH
> 
> [1] OASIS Extensible Resource Identifier (XRI) TC 
> http://www.oasis-open.org/committees/xri/
> 
> [2] OpenXRI
> http://www.openxri.org/
> 
> 
> 
> 
> 
> _______________________________________________
> 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: Dick Hardt <[email-masked]>
Date: Wed, 25 Jan 2006 22:53:30 -0800

> information provider to be considered by the relying party.

I generally agree Phillip.

In the identity gang discussions we have called these claims instead  
of identity information. Identity having a vague meaning.

I see (2) requiring not only a trust relationship with the asserting  
party by the relying party (something that is social, not technical),  
but also a mechanism for the relying party to know it is a valid  
assertion, which requires some verification mechanism such as PKI.

-- Dick

---

From: James Benedict <[email-masked]>
Date: Thu, 26 Jan 2006 07:35:40 -0500 (EST)

--- Dick Hardt <[email-masked]> wrote:

> > party understands that the data is self asserted.
> Attribute value  
> > pairs

I gotta disagree to a certain extent with this one.  I
don't consider these two separate types of Identity
Information, I consider it an arbitrary decision about
the "required" reliability of certain attributes.

For example: A photo, for the purposes of a web-forum
avatar doesn't have to be very reliable ... in most
cases, it isn't even expected to be really
representative.  On the other hand: a passport photo,
drivers license or even a company access id photo
needs to be verified by a trusted 3rd party.

> of identity information. Identity having a vague

All the more reason to agree to common terminology, so
we all know what the heck each other are talking about
:)

> assertion, which requires some verification

Agreed.  I just don't believe that we should treat the
(1) and (2) as separate types of attributes.  Maybe
the should be represented as a triple
{attribute,value(s),verification(s)} where
"verifications" (or whatever, someone give it a name)
is a codification of the mechanism Dick was alluding
to above.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 26 Jan 2006 08:20:18 -0800

> needs to be verified by a trusted 3rd party.

Hmmm. Not sure what you are disagreeing with.

Yes, they are both photos. One is just the data, the other has been  
asserted to be associated with the user by a *trusted* third party.
The assertion is what makes them different.

> we all know what the heck each other are talking about

Totally agree!

> is a codification of the mechanism Dick was alluding

They are both attributes or properties or claims. (2) has a modifier  
that means it has been asserted.

btw: I prefer not to use the term "attributes" since it has a  
specific meaning in XML, "the attribute attribute ..." gets  
confusing ...

-- Dick

---

From: James Benedict <[email-masked]>
Date: Thu, 26 Jan 2006 11:35:05 -0500 (EST)

--- Dick Hardt <[email-masked]> wrote:

> >>> 2) Third party assertions (reputation,
> spamminess,
> >> star alliance gold
> >>> etc.)
> >>>
> >>> The first type of information is not difficult
> to
> >> manage, the relying

I agree with your explanation.  That just isn't what I
read in the first post.

In your explanation I see two types of "information"
1) the data (photo, reputation, email, nickname, etc.)
2) the assertions on the data ("DMV-validated photo",
"unvalidated nickname")

The way I read the original post, it sounds like
Phillip is describing two types of "data":

1) self-asserted 
2) third-party asserted

I'm all for saying that data can be self-asserted or
third-party asserted... but I don't want to start
categorizing the information based on what "can" be
self-asserted vs. third-party.

... snip'd recursive aggreements ...

--
James

---

From: Dick Hardt <[email-masked]>
Date: Thu, 26 Jan 2006 08:43:46 -0800

> self-asserted vs. third-party.

Glad we agree and that we have "clarified" Phillip's post!

Phillip, are you in agreement? (don't want to speak for you)

-- Dick

---

From: Peter Davis <[email-masked]>
Date: Thu, 26 Jan 2006 12:50:58 -0500

> information provider to be considered by the relying party.

The is a sub-type of type 1 above, IMHO:

1a) Self-Asserted, but verifiable by a third party.

Today's Credit Card transactions (esp those conducted via web sites) fall
into this type. Tho I wonder, having written this, if it is some hybrid of 1
and 2?

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

---

From: [email-masked]
Date: Thu, 26 Jan 2006 14:00:06 -0500

I also agree with Phillip that there are two types of claims. (I like that word better.)
 
I would point out that in the proposed protocol, the "agent" is actually making the claims on behalf of the user.  The whole point of a "Homesite Inspection" step performed by the relying party ("Membersite") in the draft is to establish the reputation of an endpoint for speaking on behalf of the user. However the agent and the user are so closely aligned that making this distinction is probably overkill.
 
A more important difference is that case (2) requires some sort of name that can be used by the third-party to refer to the subject of the claims.  Case (1) doesn't have this need, since the subject is always the "current user". Naming always seems to be the most difficult thing to agree on.  The name can be:
   1) a key value (public key) or the hash of a key value
   2) a unique value generated by the relying party to represent the user for this session
   3) a globally unique name (good luck with this one!)
   4) a name given by some naming authority (which must also have a name)
 
A DIX protocol that only supported case (1) claims would avoid the whole naming issue.  This might be a good thing to focus on, so that something is accomplished in a shorter period of time.
 
Terry Hayes
 
-----Original Message-----
From: Dick Hardt <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Sent: Wed, 25 Jan 2006 22:53:30 -0800
Subject: Re: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter)

On 25-Jan-06, at 9:25 PM, Hallam-Baker, Phillip wrote: 
 
> party understands that the data is self asserted. Attribute value > pairs 

In the identity gang discussions we have called these claims instead of identity information. Identity having a vague meaning. 
 
I see (2) requiring not only a trust relationship with the asserting party by the relying party (something that is social, not technical), but also a mechanism for the relying party to know it is a valid assertion, which requires some verification mechanism such as PKI. 
 
-- Dick