some questions on OpenID AX 1.0 draft 4

[Dick Hardt]

Hi Mark, for some reason I just saw this post, answers and questions  
inserted ...

On 5-Apr-07, at 9:47 AM, Mark Wahl wrote:

>
> http://openid.net/specs/openid-attribute-exchange-1_0-04.html
>
> 1. Section 2 states that the store operation "saves or updates
> attribute information on the OpenID Provider."
>
> How does an RP delete an attribute when updating information on the
> OP?

The OP is not a repository for the RP. It is a repository for the  
user. RPs store data at the OP that the user might find useful  
somewhere else.

>
> 2. Section 3.2 states that "If an attribute type identifier URI
> can be resolved then it MAY be dereferenced to retrieve a
> description of the property."
>
> In this protocol, who is doing the dereferencing?  Would an OP
> return an error during a store if it resolved the URI and there was
> no description of the property there?

This feature was created to allow an OP to dereference an attribute  
requested by an RP that the OP did not understand and dynamically  
assist the user in providing the attribute.

The meta-data could provide labels and syntax so that the OP could  
prompt the user for the value, or the meta-data could indicate to the  
OP where the user could go do get the attribute.


>
> 3. Section 3.3 states that an attribute value MUST be a UTF-8 string.
>
> Are any UTF-8 characters permitted?  How is a newline escaped, as
> Section 4.1.1 of http://openid.net/specs/openid- 
> authentication-2_0-10.txt
> states that "A key or value MUST NOT contain a newline".

escaping of chars if needed is dependent on the syntax of the data in  
the attribute. The idea this was out of scope of AX and dependant on  
specific attributes.

>
> Presumably RFC 2482 characters (plane 14 language tags) are OK?  Or  
> are
> language tags of values carried through some other means?

UTF-8 would preclude language tags would it not?

>
> How can the RP determine the maximum value length that an OP will
> support for a particular attribute?

no upper limit defined ... suggestions?


>
> 4. Section 5.1 states that "Attribute aliases MUST NOT contain
> newline and colon characters,... they also MUST NOT contain commas."
>
> What is the significance of a period character?  Can an alias
> "contain" a period?

no -- looks like that should be added to the spec

>
> What is the maximum length of an alias string that an RP can expect
> an OP to support?

suggestions?


>
> 5. Section 5.1 states that if openid.ax.if_available parameter is  
> present
> "The OpenID Provider MAY provide the identity information specified  
> in this
> parameter.".  How does the RP determine the schema of the provider  
> to know
> what to ask for?

Don't understand this question.

>
> 6. Section 5.1 states that "openid.ax.count.<alias>" is "the number of
> values for the specified attribute alias the Relying Party wishes to
> receive from the OpenID Provider. If present, the value MUST be  
> greater
> than zero. If absent, exactly one value is requested. OpenID Providers
> MUST NOT return more than the number of requested values."
>
> What is the largest value of count that an RP that wants "all values"
> can submit that an OP will support?  2^31? 2^32? 2^63?

See thread with Josh. Suggested value?

>
> 7. Section 5.2 states that "The value of the openid.ax.type.<alias>
> parameter specifies the type identifier URI for the attribute referred
> to as <alias>. MUST be present if, and only if, this exact parameter
> was included in the fetch request."
>
> It's not clear to me how subtyping of attributes is handled.
>
> Suppose the OP holds a 'person' with attributes
>
> ldap://..../cn=schema#cn:  John Smith
> ldap://..../cn=schema#cn:  Johnny Smith
> ldap://..../cn=schema#surname: Smith
> ldap://..../cn=schema#givenName: John
> ldap://..../cn=schema#patronymic: Paul
>
> Now the attribute types ldap://..../cn=schema#cn,
> ldap://..../#cn=schema#patronymic, ldap://..../cn=schema#surname,
> ldap://..../cn=schema#givenName are all subtypes of a generic  
> attribute
> type ldap://..../cn=schema#name.  In LDAP directories, when one  
> asks for
> a 'name' attribute, that's a shorthand for asking for any of the  
> naming
> attributes, which can be useful if the requestor doesn't know in  
> advance
> what schema attributes the server uses for naming people.
>
> A RP issues a fetch request for ldap://..../cn=schema#name, asking for
> "any naming information" .  The OP doesn't have a #name attribute  
> in that
> person, but does have #cn, #surname, #patryonmic and #givenName  
> attributes.
> How should the OP encode these types in the fetch response to the RP?

AX has a simple model that you ask for an attribute and you get it.

If the meta-data states that different types are equivalent, then you  
can get one of those.


>
> 8. Section 6.1 states that "openid.ax.value.<alias> assigns a value  
> to the
> attribute referred to as <alias>."
>
> Is an OP receiving a store response required to save the alias  
> provided by the
> RP for any purpose, or is the alias merely used in a particular  
> protocol
> interaction?

alias is just for the protocol

>
> 9. Section 6.1 states that "openid.ax.value.<alias>.<number>  
> assigns a value
> to the attribute referred to as <alias>. The <number> uniquely  
> identifies the
> index of the value, ranging from one to the value specified by
> "openid.ax.count.<alias>".
>
> Is the OP required to preserve the order?


no

>
> 10. Is it legal for the values of a multi-valued attribute to be  
> bytewise
> identical, e.g.:
>
> openid.ax.value.fav_movie.1=Movie1
> openid.ax.value.fav_movie.2=Movie1

good question. What do you think?

>
>
> 11. How can the RP determine the maximum value count that an OP  
> will support?

not defined -- suggestion?

>
> 12. Is it legal for the store request to be used to add values without
> restating existing values, e.g.
>
> openid.ax.type.fav_movie=http://example.com/schema/favourite_movie
> openid.ax.count.fav_movie=1
> openid.ax.value.fav_movie.3=Movie3
>
> If a store request includes fewer values than what are stored, then  
> presumably
> the OP will delete the other values?

OP implementation issue that likely will ask the user what to do

>
> 13. How is a race condition avoid if two RPs both want to
> 'add' a value to the same attribute.  (e.g., RP blockbuster wants to
> add movieX to my "movie's I've seen" attribute, and RP netflix wants
> to add movieY to my "movie's I've seen" attribute).
>
> Maybe there could be a magic number of "greater than any other"?

This is a user oriented protocol, so it would be interesting to have  
two stores happen at the same time.
A good OP would just merge all the attributes.

>
> 14. Similarly, there doesn't seem to be support for counter-valued
> attributes in the OpenID attribute exchange.    In order for an RP to
> increment a value stored in the OP, the RP would need to fetch the
> old value, add, store the new value.
>
> How some protocols handle #12 and #13 is through an only-if-unmodified
> flag.  E.g., the fetch response returns a cookie value, with the  
> property
> that if the attributes are modified, a subsequent fetch response will
> return a different value for the cookie.  The store request optionally
> includes a field with a cookie.  If the cookie is provided, then  
> the OP
> will check if the cookie is the same as that in the entry.  If it  
> matches,
> then the store operation proceeds, otherwise the store fails with a
> "re-fetch needed" error.

The data at the OP is an unordered list as far as the RP is concerned.

>
> 15. Section 6.2.2 specifies the "openid.ax.status.description"  
> parameter.
>
> What locale is this parameter text in?

good question -- likely the locale that the rest of the HTTP message  
is in

>
> Is this message intended to be shown to an end user?

yes

>
> 16. It would be useful if there was an optional parameter in the  
> storage
> failure that lists the attribute(s) which caused the problem.

do you think this is still needed given that storage is not intended  
for the RP, but for the user?

-- Dick