Specifying identifier recycling

[Johnny Bufu]

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