In order to make the prescribed change, new text is needed:
* New subsection for section 7 (Accessing Protected Resources) providing
guidelines for use of the new 'resource access error response' error registry:
1. What are the valid cases in which a 'resource access error response' may
be registered:
- OAuth-related HTTP authentication schemes? E.g. Bearer.
- General purpose HTTP authentication schemes with OAuth binding? E.g.
MAC.
- Other HTTP authentication schemes not related or useable with OAuth?
E.g. Digest-like
2. Clarify how the parameter may be transmitted (e.g. HTTP authentication
headers, response payload)?
3. Any requirement or recommendation to opt-into the registry by future
OAuth or other authentication schemes (e.g. MAC)?
* New text for explaining the new location for section 8.5
1. Text for any changes in the parameter value character set to align with
common transport restrictions for protected resources errors
* New text for publishing each parameter location in a separate table for
section 11.4.1
1. Is there a requirement for a parameter to carry the same meaning across
locations, now that each location is registered in a separate record?
2. Clarify registration process for parameter used across locations
(multiple entries or one template?).
As soon as the new text is posted to the list and agreed upon by the working
group, I will make the change to the document.
EH
> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Hannes Tschofenig
> Sent: Tuesday, May 15, 2012 2:27 PM
> To: oauth@ietf.org WG
> Subject: [OAUTH-WG] Error Registry: Conclusion
>
> Hi all,
>
> on May 8th we called for consensus on an open issue regarding the location
> of the error registry. Here is the call for comments:
> http://www.ietf.org/mail-archive/web/oauth/current/msg08952.html.
>
> Thank you all for the feedback. The consensus is to create the registry in the
> core document.
>
> Section 11.4.1 already sort-of creates sub-registries to illustrate where the
> different errors can be used. This is needed since some of the errors may
> only appear in certain error responses. Hence, we need add another one to
> this list (suggestion: 'resource access error response'). In fact, I would
> prefer
> IANA to create separate tables for each of these sub-registries to avoid
> confusion for the reader (instead of putting everything into a single table).
>
> We believe that these changes are really minor and address IESG feedback.
>
> Ciao
> Hannes & Derek
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
