Comments on: OpenID Attribute Exchange

By: James Henstridge

James Henstridge — Wed, 28 Nov 2007 00:31:37 +0000

Will: one thing to keep in mind is that some OPs may only have limited support for attribute exchange: they may support a set of well known attributes, but not arbitrary attributes. Furthermore, it is going to be a while before RPs can depend on the presence of this extension (outside of closed systems, that is).

Johnny: that looks pretty interesting. Including enough information in the value to perform verification does partially solve the problem. It pushes the need for a special RP ↔ OP trust relationship and changes it to an RP ↔ attribute signer trust relationship. It still isn’t clear how to handle these trust relationships on the open internet.

LionsPhil: the specification mentions the 404 status code. If you think 403 is better, consider joining the OpenID specs mailing list and suggesting the change.

By: LionsPhil

LionsPhil — Mon, 26 Nov 2007 22:16:23 +0000

I’m not sure that 404 is the most applicable HTTP status code to use here. 403 might be clearer.

By: Johnny Bufu

Johnny Bufu — Mon, 26 Nov 2007 19:29:16 +0000

James,

This is a great review of Attribute Exchange, thanks for taking the time to write it up! A few comments:

Re: unsolicited positive assertion

They are mentioned in the spec in a couple of places:

10. Responding to Authentication Requests
“Relying Parties SHOULD accept and verify assertions about Identifiers for which they have not requested authentication. OPs SHOULD use private associations for signing unsolicited positive assertions.”
http://openid.net/specs/openid-authentication-2_0-12.html#responding_to_authentication

11.2. Verifying Discovered Information
“If the Claimed Identifier was not previously discovered by the Relying Party (the “openid.identity” in the request was “http://specs.openid.net/auth/2.0/identifier_select” or a different Identifier, or if the OP is sending an unsolicited positive assertion), the Relying Party MUST perform discovery on the Claimed Identifier in the response to make sure that the OP is authorized to make assertions about the Claimed Identifier.”
(this clarification was added after draft12, so it’s only in SVN, not yet published)

Re: verified attributes

Attribute Exchange deals only with the transport of the attributes, not with their content, acquisition, source, trust. There’s a separate extension proposal that deals exactly with the trust issue for attributes:

OpenID Signed Assertions
http://www.mail-archive.com/specs@openid.net/msg00907.html

A demonstrative implementation of this (using verification of emails as the example) is available at:

https://verify.sxip.com/email/
(retrieve a signed assertion saying that Sxip has verified your email address)

https://verify.sxip.com/demorp/
(present the signed assertion to an OpenID 2.0 RP using Attribute Exchange, which trusts Sxip with the verification process)

Johnny

By: Will Norris

Will Norris — Mon, 26 Nov 2007 18:17:22 +0000

Excellent explanation of AX, James. I’m quite curious to see how RP will try to use attribute storage down the road… I imagine there will need to be some best practices from the community as to what is and is not appropriate to push back to the OP to store. I can easily imagine an RP going crazy with it and basically treat the OP as its database. I would also be careful about limiting the scope of AX, particularly your first caveat — “Any attribute values provided to the RP are self-asserted.” I’ve been doing some work on bringing OpenID to college campuses, and initially I imagine that *none* of the attributes will be self-asserted unless the campus has alternate means for modifying the data… they will all come for the university’s enterprise data store. AX is just a format for carrying attributes on the wire… it says nothing about where the data came from. But I guess your point is that if there isn’t a pre-existing trust relationship, the attributes may as well be self-asserted because you simply don’t know.