- Concern that 3 and 3.1 do not clearly show a way for a native client to
provide client_id (to identify the client only) without doign authentication.
Proposed new text, insert in bold:
"In addition, the authorization server MAY allow unauthenticated access
token requests when the client identity does not matter (e.g. anonymous
client), when client authenitcation is not practical, or when the client
identity is established via other means."
- Last paragraph, section 3, proposed new text, reversing the order, putting
"since ..." at the end of the sentence:
The authorization server MUST require the use of a transport-layer security
mechanism when sending requests to exchange an the token endpoint since
requests using a method other than client password this authentication method
result in the transmission of clear-text credentials.
- 3.1 edit first paragraph
Delete: "(the client identifier together with a shared symmetric secret secret)"
- 4.1.2.1. Error Response -- Character set for error_description
becomes
"OPTIONAL. Human-readable UTF-8 encoded text providing additional
information, used to assist to the developer in understanding the error that
occurred."
- 4.1.2.1. Error URI -- "resource owner" becomes "developer"
error_uri
OPTIONAL. A URI identifying a human-readable web page with
information about the error, used to provide the developer
with additional information about the error.
- 4.1.2.1. Error -- remove HTTP 4xx and 5xx error code as an allowed
"error" value
- 4.2.2.1. Error Response -- ibid
This is considered a possible area for confusion between the HTTP error code
and the error code returned in protocol.
TODO: Eran H-L to look at which HTTP error codes should be mapped in to
protocol specific error codes.
- 10 Security considerations....
- 10.10 Session fixation...
Breno does not feel that session fixation is properly described nor dealt
with.
Igor is providing reference links to session fixation description (mail to the
list).
TODO: br...@google.com is working on new draft language.
- 10.13. XSRF/CSRF Prevention
TODO: Breno and Bill M. working on new draft text.
- 9. Native applications
Objections that this recommends against things that are extant implementations.
TODO: Chuck N. to draft revised text.
- 4.5 Extensibility
TODO: Hannes will look at policy for using IETF URN
TODO: Mike J./Chuck N. to draft 4.5.1 subsection on assertions. Clarifying the
use case there and suggested behavior.
- Proposed additions
- "Immediate Mode" with display= and response=
- response_type={none, cookie}
TODO: Paul T. to send proposed requirements to the list.
TODO: Eran to add extensibilty language for this based on requirements.
- "RedirectURI" should be optional
TODO: Eran to send mail to the list proposing language changes to either change
this from REQUIRED to OPTIONAL and add clarifying language, or leave as
required and add a pre-defined value for "we're not actually using this".
- 4.3 (and 3.1) Username/Password
Need to figure out what the encoding will be here, since these can be outside
the ascii charset.
TODO: Peter St.A to review the language.
- Discussion on client credentials -- Tony Nadalin.
TODO: Tony N./Chuck N. to propose new spec to handle assertions both for
authentication and authorization.
========================
Moving on to BEARER TOKENS
========================
MIke J. reviewing changes in Draft 5.
- 2. Authenticated requests
Discussed possible language change and oped for no change.
- 400 vs 401 return
TODO: Mike Jones to follow up with HTTP WG or representatives and ask whether
there are objections.
NOTE: Mark Nottingham (in the HTTP community says that either 400 or 401 are
acceptible in most cases.
- can we move from 403 to 401?
Eran's statement is that 403 is sematically correct in HTTP. Probably true.
========================
Moving on to MAC TOKENS
========================
Eran ran through the current status.
Only significant issue at this time is body hash. Seems to be a thorny issue,
he is looking for actual implementer experience.
========================
Moving on to SAML
========================
Brian Campbell: No recent feedback on the list. Not sure whether that's good
or just no attentionon SAML.
========================
Move to adjourn... Adjourned._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
