[OpenID] OpenID Identity Consolidation

[Nate Klingenstein]

Chris,

> This is where Portable Contacts comes in, since we already accommodate
> sending other known identifiers for a person.

Just looking at the draft spec for the first time now, it's looks  
like a pretty large and structured data set.  I see no reason the  
same information couldn't be conveyed using AX as a sort of transport  
layer, at first glance.  I think the SREG/AX duplication is  
counterproductive.  SREG uses its own namespaces, but PoCo seems to  
use its own protocol, which is a more significant divergence.

Is there a strong reason not to see all this data as attributes?  It  
seems easier to just treat these sets of information as standard  
object classes to be populated appropriately and transported using  
existing mechanisms.  That would be better for implementers and  
reduce confusion by deployers, increasing the chance they could  
implement privacy controls, for example.

And one more bit of consolidation: is there a place where I can track  
all the specs this community is generating?

> I can't say whether it's wise to separate OpenID identifiers from
> others, though, and I also don't know how well RPs will trust data
> provided either via AX or PoCo (i.e. if a list of OpenIDs is provided,
> will/should an RP take for granted that the list is a valid list of
> verified identifiers?).

I think it's good to flag an identifier's type, in case the RP wants  
to make further use of it, e.g. additional queries.

Trusting attributes is a separate problem which requires a trust  
model.  There are handshakes, federations, reputations, hierarchies,  
and more.  I'd love to see these protocols transport information  
about trust.

I think TX is going in the right general direction, and I applaud the  
brainstorming that went into it.  However, it seems to be weakly  
bound to the authentication event and attributes.  The use of a nonce  
might refer to overloading the nonce used in the initial  
authentication event, but the draft isn't clear.  It probably  
wouldn't work for non-repudiation or integrity protection of  
attributes, for example, because the attributes, identifier, etc. are  
never signed and are very loosely bound.

Maybe it's time to begin cobbling these things together into  
something less organic.

Thanks for your ideas,
Nate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081102/0b10efda/attachment-0002.htm>