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