correlating an OpenID value being stored to the OP attribute that should hold it

Mark Wahl Mark.Wahl at informed-control.com
Wed May 16 19:03:40 UTC 2007


In the discussion of schema at the IIW2007 there was a
scenario in which an RP asks for an attribute of an OpenID identity
provider, but that provider doesn't hold that specific attribute,
only one or more related attributes.

For example, the suppose RP fetches for an attribute whose URI is
axschemas.org/schema#SingleValuedSaluation

and the OP holds two attributes
foo.com/schema#ProfessionalSalutation
	Dr. Smith
	John Smith, MD

foo.com/schema#InformalSalutation
	John

Then the OP prompts the user to select which one to return in the
fetch response
  	Dr. Smith (Professional)
	John Smith, MD (Professional)
	John (Informal)
	(none)

If the OP returns only that #SingleValueSalutation has the value
chosen by the user, e,g. "John Smith, MD", then the knowledge that
this value comes from the #ProfessionalSalutation attribute is lost.
If the RP only is interested in querying this information, then
this lost knowledge isn't a problem for the OP, however it is a
problem if the RP subsequently performs a AX store operation back to
the OP to update this information.

Later, if the RP performs a store to update the
axschemas.org/schema/#SingleValuedSalutation, the semantics of
the attribute is that it is single-valued, so the new value should
replace an existing value.  However, since the OP doesn't hold that
attribute, it needs to be able to determine which attribute
(#ProfessionalSaluatation or #InformalSalutation) the store refers to.
It is desirable that the OP be able to 'tunnel' the information
of which actual attribute this is replacing through the RP, even if the
RP doesn't recognize the distinction between the forms of salutation,
so the OP can know which attribute the RP is referring to.

This issue could be addressed by a parameter in the OpenID attribute
exchange included in the fetch response and store request.   Both of
these are optional.

For example,

Fetch Response Format

openid.ax.origin.<alias>.<number>

	Identifies the origin attribute of the value referred to
	by the <alias> and <number>.  This parameter is returned if
	the fetch request indicated a generic attribute, and
	the OpenID provider did not hold that generic attribute,
	so the OpenID provider is returning a value of a more
	specific attribute.  The format of this parameter is a URI.

Store Request Format

openid.ax.origin.<alias>.<number>

	Identifies the origin for the value referred to by the
	<alias> and <number>.  This URI is provided by the RP if
	the RP is updating an existing value, and the value being
	updated was accompanied by an
  	openid.ax.origin.<alias>.<number> in an earlier fetch
	response.


Mark Wahl
Informed Control Inc.



More information about the specs mailing list