Subject: [OAUTH-WG] Using access token in draft-ietf-oauth-v2-http-mac

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 01 Mar 2013 12:23:15 +0000

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
>