Skip to main content

Minutes for OAUTH at IETF-92
minutes-92-oauth-2

Meeting Minutes Web Authorization Protocol (oauth) WG
Date and time 2015-03-23 18:00
Title Minutes for OAUTH at IETF-92
State Active
Other versions plain text
Last updated 2015-03-24

minutes-92-oauth-2
OAUTH WG

WG STATUS
Oauth Assertion Framework – RFC Editor Queue
JWT - RFC Editor
JWT Bearer  - RFC Editor

Proof Key for code exchange – to IESG
PoP Architecture – to IESG
PoP Semantics for JWT WGLC in Progress
Token Introspection – Shepherd write up

Token Introspection – Justin
Made changes from WGLC most notably some specific requirements for “active”
Open Issues: Registries
Main issues is trying use the JWT registry with Token Introspection, so there
is a (1) proposal to extend the JWT registry or (2) to create a new registry
and seed it with the JWT registry,  (3) and last proposal is to create a new
introspection registry-only Mike – is for option2 to be aligned with how this
has been done before Brian – 2 separate registries are needed, so option 2
would work John – Does not want the JWT to be a dumping ground, so separate
registries needed Poll – option 1 – 0 votes, option 2 – 12, option 3 -1

POP Semantics – Mike
WGLC ends soon, new comments came in so need to talk about these and push a new
draft out Brian – Made some editorial comments, concerns over the CNF and the
structure. Review document – Justin, Nat

John Bradley gave overview of Proof of Possession
Proof-of-Possession Blog post from John Bradley see
http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.html
Discussion over how to stay in step with the industry, other ietf work

PoP AS to Client Key Distribution  - Hannes and John Bradley
Open Issues – can asymmetric keys be used with more than one resource server
Protect Refresh Token as well as Access token ? TBD, need usecase
Need to have more discussions on client held keys and server keys
There needs to be a matrix of all the options that may be available  (will call
out the various redundancies)

HTTP Message signing
Tie and OAUTH token and signature to a specific HTTP request
This is not binding to the TLS session
There are other ways to do this, OAUTH 1.0 and AWS

OAUTH Token Exchange
ActAS, onBehalfOf functionality
Stable drafts
Need more input and more eyes on this
Phil – so folks are not interested in the expensive token chains and validating
Brian – none of his feedback has been considered

In-official meeting will be scheduled during this week.

Open Redirectors
Leaks  information in the fragment and referrer, this applies to all protocols
that use redirects Some of the mitigations
              Append fragments to all redirects
              Internal redirect
              Append content-security-policy Header
              Include Referrer meta tag
So do we do something specific in OAUTH like put this into the security document

Suggestion to update the OAuth Thread document to include these types of
recommendations. No decision made.

Destination Claim – Brian
A new claim for specifying the destination of the JWT, not the same as audience
(who) but where is the key, A single value destination, may need to make this a
multi-value

Discussion needed how it is different to the audience claim.

End of meeting