[OpenID] Can one use Generic OpenIds

[Johnny Bufu]

On 24-May-07, at 1:32 PM, Peter Watkins wrote:

> On Thu, May 24, 2007 at 09:50:01AM -0700, Johnny Bufu wrote:
>>
>> 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 MUST accept any and all "normal"  
identifiers; the same policies can be applied by RPs to those as well.

> 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.

Performing OpenID verification is one such resource, for which RPs  
are entitled to have policies.

> 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.

It would actually be more code to actively recognize a directed  
identifier in a response and reject it  at that point based on this  
criterion. The SHOULD is there because these policies could be  
implemented at a different level (blacklists in firerwalls for example).

I understand you have an issue with a SHOULD being present for the  
directed identity case, but not explicitly stated for the "normal"  
case. Since it can't be a MUST, I see two possible options:

a) remove it: it won't be clear that OPs can actually send different  
identifiers in the response;

b) add another SHOULD for the "normal" case: I don't see it helping  
the spec in general, or your issue.


Do you have a suggestion / proposal on how to fix this so that it  
addresses your concern?


Johnny