[OpenID] Can one use Generic OpenIds

[Peter Watkins]

On Thu, May 24, 2007 at 09:50:01AM -0700, Johnny Bufu wrote:
> 
> On 24-May-07, at 7:49 AM, Peter Watkins wrote:
> > 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.
> 
> That is a SHOULD and not a MUST because the RP has, in many points of  
> the protocol flow, the choice of stopping a transaction for  
> security / policy / etc. reasons. This is one such instance.
> 
> Doing so does not break conformance (or reliability) with the OpenID  
> protocol, it only results in 'denial of service' based on RP policy.  
> If however the transaction completes successfully, it does so in a  
> consistent way.

By "not reliable" I mean that OpenID 2.0 is not a reliable option for
us, given that our main use case would rely on "directed identity" and
the special identifier_select URL. If the spec allows RPs to reject
directed identifiers, then OpenID simply isn't usable/reliable for us.

Can you give some examples of reasons an RP might accept "normal" 
OpenID usage but not identifier_select and directed identity?
Nothing in the spec says that an RP, having successfully verified an
OpenID identity, *must* give the holder of that identity *any* access
to the RP's offerings. I don't see how requiring an RP to recognize
a directed identity as a legitimate OpenID identifier interferes with 
the RP's ability to enforce whetever policies they choose.  But I do
see how this SHOULD language gives implementers the option of writing
less code in a way that supports the "normal" OpenID model and complies
with the draft 11 spec but kills our main use case.

Thanks,

Peter