[OpenID] Can one use Generic OpenIds

[Peter Watkins]

On Thu, May 24, 2007 at 03:51:48PM +0200, Boris Erdmann wrote:

> gets directed to OP
>  |
> V
> user authenticates and selects "group id" to be returned
>  |
> V
> gets directed to RP
>  |
> V
> RP now knows both ids.
> 
> Is it up to the protocol spec to define how an RP has to handle
> that data? In fact it's the RP that finally defines the semantics,
> meaning or role of the group id. OTHO it's the OP that makes
> a group id shared between several personal ids. So there must be
> consensus between those parties anyway.

Why does section 10.1, as Johnny highlighted in another thread, say 
only that RPs "SHOULD accept and verify assertions about Idenitifers
for which they have not requested authentication"? It seems to me that
both this group/role ID model and the "directed identity" model
rely on the RP accepting whatever the OP returns as openid.claimed_id
as the user's identifier (subject to double-checking the OP's authority
via discovery as descibed in 11.2 [thanks again, Johnny]). If the RP
chooses not to accept a "group id" assertion because the group ID
isn't an ID that the RP sought to authenticate, then this use case is
not reliable.

Section 10/10.1 suggest that the OP would send a "new" identifier (one
not sent in the RP's request) if the RP set openid.identity to the
special identifier_select URL, but the SHOULD clause I quoted above
seems to make even that very deliberate "directed identity" use case
not reliable. 

Should the "SHOULD accept and verify assertions about..." language in
10.1's openid.identity section be changed to a MUST requirement so
that directed identity and group IDs are reliable?

Also, I think this language in 10.1 include language like "and MUST 
perform discovery on identifiers for which they have not requested 
authentication as described in section 11.2" to better highlight
the RP's responsibility to use post-assertion discovery to prevent
OPs from forging improper assertions.

-Peter