On 30-May-07, at 1:28 PM, Josh Hoyt wrote: > How should the discovery process work? > How should fragments work with delegation (both as the claimed > identifier and the provider-local identifier)?
Here's how I see the fragments approach working: a) Discovery: strip the fragment from the user-supplied identifier before initiating discovery. b) Auth response: if a different op-local identifier is not specified, the claimed identifier sans fragment MUST be used as the value for openid.identity. c) Verification of discovered information against auth response fields: strip_fragment(openid.claimed_id) == discovered claimed id openid.identity == discovered op-local id (no change) d) Identifying the user: openid.claimed_id in auth response SHOULD be used as a key (no change) strip_fragment(openid.claimed_id) MAY be used as user-visible id From your list of issues: > 1. Using a URI fragment with a uniquifying value: > > * Potential problems with initiation and discovery No issues with the proposal above (but please think over and confirm!) > * Potential problems with inconsistent behaviours on OpenID 1 sites OPs should send claimed IDs with fragments only for OpenID2 messages. > * URLs that user see may be ugly or inconsistent across sites (if > some relying parties do and others do not strip the fragment > before display) Maybe enforce that fragments SHOULD NOT be used for display? > * There is no difference between different versions of a > *user-displayed* identifier (users can't tell if a reference to a > URL in the wild belongs to the current ownder of a URL or another > user). Not sure how RPs can be notified and then how they should act when an identifier gets recycled. Do we need to deal with this? Here are three scenarios and what would happen in each case: -------------------------- no delegation: user-supplied id: http://example.com/user#1234 or: user-supplied id: http://example.com/user discovery: claimed id = http://example.com/user op-local id = http://example.com/user auth request: openid.claimed_id=http://example.com/user openid.identity=http://example.com/user auth response: openid.claimed_id=http://example.com/user#1234 openid.identity=http://example.com/user ---------------------- delegation (1): user-supplied id=http://blog.com/ http://blog.com/ delegates to http://op.com/user#4567 discovery: claimed id=http://blog.com/ op-local id=http://op.com/user#4567 auth request: openid.claimed_id=http://blog.com/ openid.identity=http://op.com/user#4567 auth response: openid.claimed_id=http://blog.com/ openid.identity=http://op.com/user#4567 ---------------------- delegation (2): user-supplied id=http://blog.com/#1234 http://blog.com/ delegates to http://op.com/user#4567 discovery: claimed id=http://blog.com/ op-local id=http://op.com/user#4567 auth request: openid.claimed_id=http://blog.com/ openid.identity=http://op.com/user#4567 auth response: openid.claimed_id=http://blog.com/#1234 openid.identity=http://op.com/user#4567 - a binding between http://op.com/user#4567 and the http://blog.com/ #1234 claimed id must be done somehow by the OP - do we need to support this use case? ---------------------- Johnny _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs