Hi Hannes,
the proposed Authenticator text says:
"access_token
CONDITIONAL. The access_token MUST be included in the first
request from the client to the server but MUST NOT be included
in a subsequent response and in a further protocol exchange.
"
Why MUST is there ? And how the server can determine it is the first
request from a given client ?
Next, the example showing a client getting an access token + session key
from AS shows a long base64 encoded value - I don't mind, just wonder
does that simply provides for transporting tokens like JWT token (fine
as long as one can provide a simple token) ?
Thanks, Sergey
On 25/02/13 12:46, Hannes Tschofenig wrote:
Hi all,
I just submitted an updated version of the draft-ietf-oauth-v2-http-mac-03.txt.
I would like to point out that this is **discussion input** -- not agreed
content. Anything in the document is subject to change!
You also may notice that there are a few questions in the writeup.
I was trying to more specific about some of the design aspects that folks had
proposed during the last few months.
I have also re-submitted the draft-tschofenig-oauth-hotk, which includes a TLS
and a JSON-based solution approach.
In general, the open questions still seem to be related to
* Key distribution: What should be described in a document? What is mandatory
to implement?
* Selective header field protection: This is something that was brought forward
in discussions and I have included a proposal of how this could look like.
* Channel Binding: Functionality is also included to deal with
man-in-the-middle attacks against TLS. There are, however, two types of channel
bindings defined in RFC 5929. Are both needed? If not, which one should be
selected?
* Integrity protection and data origin authentication in both directions: The
current writeup allows the protection to be extended to messages beyond the
initial request. This also offers key confirmation by the server and protection
of any responses.
Writing the text I also noticed that I do not quite understand how nested JWT
documents are supposed to look like. For example, how do I encrypt the mac_key
carried inside the JWT plus add a signature of all other fields? Currently, I
have just encrypted the entire payload.
I hope to have some discussions prior to the IETF meeting so that we have a
more fruitful discussion at the face-to-face meeting.
Ciao
Hannes
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
