OAuth WG Status Check

Session Topic: OAuth WorkGroup Status Check

Wednesday 1A

Convener: Hannes

Notes-taker: Phil Hunt

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Hannes listed the current set of documents that are in progress (see http://datatracker.ietf.org/wg/oauth/documents/ )

SPOP was discussed yesterday. There was concern about the name

OAuth Token Exchange - works like an assertion swap may be slightly different than the version from Justin.

Phil asked is the problem going away because people are finding other ways. Justin indicates that some are using his draft solution but its not been picked up.

Dyn Reg has had no activity. Hannes will check with Kathleen on the status.

Dyn Reg Mgmt is being published as an experimental draft. Hannes and Justin will do a shepherd write-up. The write-up went to the mailing list here: http://www.ietf.org/mail-archive/web/oauth/current/msg13717.html

The Dyn Reg Meta data document was folded into Dyn Reg and should be dropped. Hannes marked the document dead after the meeting.

Token Introspection - Hans from Ping has been implementing and has been sending comments back to Justin.

Justin gave a brief intro into the use case for dyn reg for the IIW group. In a distributed service the RS often needs to get information about the token.

There is still discussion on scale of polling. Justin suggests using caching with introspection. Phil commented that this seems to go against the scenarios that demand revocation be checked per use. The alternative pattern that can be used is pub/sub to deliver notifications to the resource.

Breno commented that clients are rarely interested in checking validation. Google is looking at both introspection and pub/sub models.

Scotty mentioned one technique is to have the AS issue different lifespan tokens based on risk. A read token might live substantially longer, while a privileged/high-risk scope would be short-lived requiring re-authentication.

Action items: According to Justin there is still some editorial clean up required.

JWT is in IESG eval plus the 3 assertion documents.

Hannes is expecting these documents to be finished in December.

Proof-of-possession documents have not made a lot of progress. The security architecture describes the use cases and requirements.

Hannes showed the POP architecture slides form the Toronto meeting and reviewed the documents. Here are the slides: http://www.tschofenig.priv.at/iiw/2014/IETF-OAuth-PoP.pptx

TLS channel-id is a new spec (resurrected) that can fit as part of the client to resource server pop — the proof is occurring at the transport layer. However this is not a message signature. The concerns are apparently focused on blocking MITM attacks and/or truly application layer security.

Breno mentioned his concern with message signing is there is no expectation of wide inter-operability. There are just too many intermediaries messing with the data. He suggests we focus on protecting the payload.

Breno mentions that a lot of the issue is in the frameworks: what happens between TLS and the actual application code.

Additional Notes

OAuth 2.0 Working Group

This was a working group meeting discussing the progress of several draft documents; specifically the OAuth Symmetric Proof of Possession (SPOP), OAuth Token Exchange, and OAuth Token Inspection draft documents.

The OAuth Token Inspection draft speaks to situations where the AZ and the API server are not the same system, thus the API server needs a mechanism to determine the liveliness of the access token (supposing the token is a reference instead of being an irrevocable encrypted blob). There was a long discussion of Push vs Pull semantics. Justin (the draft’s author) is in favor of a pull mechanism where the API server pulls liveliness information from the AZ. Another gentleman was of the opinion that the AZ should syndicate this information to the API sever, however there was efficiency and scalability concerns with this.

Access tokens may be used once and discarded, or never used, thus is makes little sense to syndicate their state to each API server. Both are valid approaches depending what is being optimized for. Justin invited edits to the draft.

The Proof of Possession discussion focused around the interactions between the RS and the client. They can be secured via TLS Channel binding, however that requires touching deeper parts of the stack. The benefit is that web service containers are free to manipulate responses, as the security lives lower down the stack. The downside is that Docker-like systems might not expose the TLS layer so adoption may be poor. Another option would be signing HTTP request headers. The pushback here is that some web service containers will manipulate some headers. A draft is in the works to canonicalize the HTTP request before signing, leaving out potentially problematic headers. This is essentially what AWS’ HTTP Request Signature V4 does.