Comments on Auth 2.0 - Pre-Draft 11

[Johannes Ernst]

On Dec 11, 2006, at 16:41, Johnny Bufu wrote:

> Hi Johannes,
>
> Josh and I went through the remaining issues, so I have addressed  
> and/or commented on some of them below.
>
> For easier tracking I've inserted [josh] after the ones that Josh  
> agreed to handle.

Looking forward to Josh's input.

Some comments on the "closed" and non-Josh issues.

>> When a message is sent as a POST, OpenID parameters MUST only be  
>> sent in and processed from the POST body.

That works, good idea.

>>>> 5.1.2.2 Error Responses, and also
>>>> 5.2.3 Indirect Error Responses
>>>>
>>>> Please clarify which language is supposed to be used for the  
>>>> "error" field, and what a party should do that receives such an  
>>>> error string, such as:
>>>>
>>>>> #  error
>>>>>     Value: Unstructured text error message that SHOULD use the  
>>>>> English language. This error message is intended to be used by  
>>>>> technically-savvy personnel to debug problems. It is not  
>>>>> intended to be shown to the end user.
>>>>
>>>
>>> My opinion is that specifying a language is out of scope for the  
>>> spec; it's up to the RP/OP to choose it. Being unstructured text,  
>>> I assume it's intended to be passed (eventually) to a human  
>>> behind the party receiving it.
>>
>> My point is that you "assume" and I "assume" and it would be good  
>> if we all assumed the same. Which is why I'm proposing to at least  
>> put a SHOULD in there for that assuming.
>
> Josh and I agreed that the language should not be specified, and be  
> left to RPs / OPs to choose the one that is most useful for their  
> users. We have edited it and it now reads:
>
>> A human-readable message indicating the cause of the error.

I think this is better, but it opens it up to the argument from the  
i18n community that this won't work -- and justly so. Which is why I  
said that the target audience is only developers, not end users.

>>>> 9.2. Realm
>>>>
>>>> Remove last sentence in first paragraph, because it is unclear  
>>>> what this is needed for. (Or, alternatively, explain why an OP  
>>>> needs to uniquely identify RPs).
>
> Rephrased a bit, so that the intent is clearer; it now reads:
>
>> The realm SHOULD be used by OPs to uniquely identify Relying  
>> Parties. For example, OPs MAY use the realm to allow the end user  
>> to automate approval of authentication requests.
>
>
>>>> Also, this is the place where to say that OPs cannot prevent RPs  
>>>> from doing something else than the realm they give.
>>
>> Resolution?
>
> Not sure what exactly you meant by "doing something else than the  
> realm they give".

We had a discussion somewhere some time about whether or not what's  
now called "realm" has any security properties. We came to the  
conclusion that there was no way for anybody to enforce "realm" and  
thus it was only to be used as an informational message to the end  
user. For example, the specified realm could be "example.com/foo/bar"  
but what the RP does is "*.example.com".

My comment was meant to suggest this could be added here.

>>>> 11.2.2.2 Response Parameters
>>>>
>>>> Not clear which values MUST be present and which not.
>>>>
>>>> Also:
>>>>
>>>> the language in this section is confusing. I don't quite  
>>>> understand it. Not sure I can make a suggestion how to explain  
>>>> it better, because so far I don' tunderstand it.
>>
>> Resolution?
>
> I'll try to rephrase the three paragraphs in there. In the  
> meantime, it would help if you could point what you found the most  
> confusing.

I'm just raising the "General Confusion Fault" ;-) That might just be  
me, however.