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

Dick Hardt dick at sxip.com
Sun Jun 3 22:22:11 UTC 2007


Hi Mark

Let me restate your concern so that I'm sure I understand it:

RP requests the axschemas.org/schema#SingleValuedSaluation attribute  
from OP

The OP has the following attributes available:
	foo.com/schema#ProfessionalSalutation
	foo.com/schema#InformalSalutation

I'm asumming that the meta-data from both:

	foo.com/schema#ProfessionalSalutation
	foo.com/schema#InformalSalutation

state they are equivalent to

	axschemas.org/schema#SingleValuedSaluation

The user then selects which one they want to return to the RP, or the  
user could even enter a different value.

The OP would then store this attribute as

	axschemas.org/schema#SingleValuedSaluation

for later retreival since it has learned what value the user would  
like to use in this case

If later on the RP interacts with the user and there is a new value,  
then the OP would store it as an additional value that could be  
returned for

	axschemas.org/schema#SingleValuedSaluation

The OP could keep the old value for

		axschemas.org/schema#SingleValuedSaluation

around in case the user wants to use it again.

-- Dick

On 16-May-07, at 9:03 PM, Mark Wahl wrote:

>
> 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.
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>




More information about the specs mailing list