Minutes IETF105: oauth: Fri 10:00
minutes-105-oauth-201907261000-01

Note takers: Phil Hunt, Tony Nadalin, and Aaron Parecki

JWT Profile for ATs - Vittorio
==============================

Phil/Tony's Notes:
------------------
Recap - Though JWTs widely used, inconsistent syntax leading to interop issues.
Common anti-pattern of clients asking for ID Tokens instead of access tokens
because they want standard token format. Limited interop due to different
syntax being used, no guidance Schema for most common entities Token Validation
Guidance

Nutshell
Provides claims layout, relationships and references, validation guidance,
security and privacy considerations.

Tony asked about validation. Is this meant to be normative? E.g. library
conformance. (e.g. best practice vs. normative draft) V: that could be a
possible outcome

00->01/02 main changes

Changes and Issues
Added introspection, privacy section, added notes to peeking into AT tokens,
IANA registry updates, removed notes on subject type, federated IdPs
       Need to discuss the difference between user/app tokens, auth_time
       behavior

Discussion

Anabel – step up Authn, password based can happen at initial access token and
then step up may happen sometime later and thus there may need to be correlation

Distinguishing between user and app tokens
Justin: Don’t let client’s choose their own id
V: agreed
J: grant_type was not very helpful. We differentiated based on if sub and
client_id are same.  Client_id alone introduced wierd signalling issues.
Clients can use client assertions on their own which is not client credential
type which introduces other issues. J: Annabelle has a draft for subject type
identifiers. That might provide more structure and could be adopted into this.
It provides rules about how subject identifiers relate to sub claim Annabelle
Backman:  I think that would be bad idea because the draft talks about subj
identifiers and not subject types. They could be handles to an app, entity org
or anything.  Maybe there is a parallel approach but I would not recommend AB:
I agree with not use grant type because it couples this to protocol
implementation details which may not make sense. If you have this it will
introduce coupling which undermines the value of the spec.

What are the key use cases being solved?
V: I tried to tease this out. The API wants to know if the client was
confidential or not. Or when they want to ensure only particular client_id can
be used for a specific purpose AB: That seems different from user vs. app. 
(3-leg vs. 2-leg) J:  I have a concrete example with medical records

Auth_time behaviour
Doubts about complexity, ambiguity
May need additional claims to provide meaning.  e.g does auth_time change
during a step-up authentication or does it point back to the original login?

Bran Campbell:  I am one of the doubters. A step up authentication in a session
after a token issued draws a lot of links between things that aren’t linked. V:
 I agree it is confusing and potentially dangerous.  This link between login
and token session already exists. B:  There can be an issue that tokens issued
against a different authentication context may have no relation to the original
login AB:  It may be useful to differentiate so that you know when a step-up
has occurred (e.g. password auth one day and MF occurs after) V;  There is
already some discussion of this in the spec along these lines.

Authenticated encryption
Should we recommend the current specs being only symmetric?
Mike Hones:  JWE does authenticated encryption.  BC: that doesn’t give the
properties we are looking for

Rifaat - unfortunately we are out of time.

Aaron's Notes
-------------

Recap of the document
* most ASs already use JWTs for access tokens
* the tokens contain the same entities but different syntax
* this happened in an organic fashion so is a good candidate for standardization
* more products are asking clients to send ID tokens instead of access tokens
to APIs
  * e.g. kubernetes, amazon
  * because the APIs need the data contained in the ID token

Summary
* defined a layout with common claims used in existing access tokens
* defined a clear relationship between resources, scopes, etc
* wrote guidance on token validation
* detailed privacy and security considerations

Example of JWT access token

Tony: is the token validation guidance meant to be normative?

Vittorio: the guidance is meant to be exact steps to follow

Changes and open issues
* changed the references to the claims to JWT specification instead of OIDC
* added introspection as a source of claim types
* expanded privacy sections
* added a reminder that clients should not peek into access tokens
* added IANA registration templates

Discussion items

Distinguishing between user and app ATs
* existing systems have a mechanism to determine whether an access token was
issued to a resource owner or an application * e.g. does the subject represent
a user or a client * there are very different ways people have achieved this
  * omit the "sub" for app tokens - IdentityServer does this
  * add a "grant_type" claim - don't want to burden the client with this
  knowledge * [sub == client_id] => app token - but doesn't work when a system
  uses different mechanisms to define sub and client_id terms * "subject_type"
  claim - indicate that the "sub" represents a resource owner or an application

Justin:
* if you're letting clients pick their own client_id you're opening up to a lot
of other problems * we tried a grant_type claim in a deployment and it wasn't
helpful, ended up dropping it and used sub==client_id claim * annabelle has a
draft for subject identifiers, in secevents -
draft-ietf-secevent-subject-identifiers-05 - there is an object structure for
user subjects

Annabelle:
* subject identifier is probably not a good idea, that draft talks about types
of subject identifiers, not types of subjects * what are the use cases where
people distinguish between user and app subjects?

Vittorio:
* sometimes the API wants to know whether the client was confidential or not
* ...

Annabelle:
* that sounds less like user vs app, and sounds like something about how the
client was authenticated and maybe the user was authenticated * when I hear
user vs app subject types I think was there a user involved at all

Justin:
* +1 to annabelle, and I have a concrete example of that

Vittorio:
* we'll go back to the list on this

Auth_time (amr, acr)

Presentation by Aaron - OAuth 2 for Browser Based Apps
======================================================

Should use AUTH_CODE FLOW
Must not return access tokens
Must use state param
Same-Domain apps.
Aaron: should this be part of the discussion if it recommends don’t use oauth
Justin:  Yes I think this is useful and we need to be clear about boundaries. 
Eg. if your backend does oauth thats fine but it is outside the scope of this
document.  One problem is the bafckend developer and the spa developer see
themselves as decoupled when they actually aren’t. V:  I agree 100% we need to
give guidance even if it is to not use oauth.  Help people to understand the
implications of the choice. If in the future they make architectural changes
than they need to understand the implications of their choice. B:  It doesn’t
necessarily mean backchoicing. V:  It depends on the developer stack and may or
may not be difficult Torsten (via Jabber): I think single-domain apps do not
belong in the BCP they should have their own BCP Aaron: Same-domain is not
normally a distinction oauth normally makes. What are the questions people are
going to ask and expect H: We should find out what the majority thinks. It
might not be an IETF topic at all (referring to single domain apps) B:  I do
agree with Justin. But there is a problem of assuming by omission. Some mention
should be made…I don’t know how.

Aaron presented other open questions
Re: PKCE vs. State usage
Daniel: Suggested using must using PKCE per security bcp.
A: that changes the spec as it states use state. Is it better to not mention it?
Jabber(unknown); leave it out

Should we remove password grant:
John Bradley:  +1
torsten and phillip (jabber unknown) : +1 each

There are a couple of items in the draft not in the security bcp.  E.g. there
are some historical aspects of implicit flow. JR: +1 A: I don’t want to
duplicate but would like to summarize and normatively refer to the sec BCP

SPA w/backend - should we have some indication that the AT may be sent to the
browser?  The problem is the AS may be confused that the browser token was
issued to a confidential client but it is flowing through a much less trusted
browser? Is anyone opposed to this (section)? Nat: Do we need to send tokens to
the browser in this case? A;  In some deployments it is much easier. We could
say don’t do that but then it limits architecture. AB: I think there are some
cases where the credentials need to flow through the browser.  The AT is
acquired by the backend and then supplied to the front end. I am not strongly
opposed to a signal but we have to be realistic that we often don’t know what
clients are doing with ATs. We might be creating a false sense of confidence in
such a signal. Torsten:  I don’t think this is a good idea without sender
constraining. BC: I tend to agree with AB.  It’s a slipper slope.  It feels not
good. Recognizing it is going to happen and providing guidance is useful V: If
there is a way to tell the authorization server the intent that might be
useful. AB: As a developer I am already dependent on something in the browser
such as cookies (sessions). We already have to think about the downstream
security. It is the same whether or not the AT flows.

Refresh tokens in SPAs

*out of time*
Aaron: I will continue the discussion on the list

Daniel - OAuth 2 Demonstration Proof-of-Possession
==================================================

MTLS is good but not great for browser. TOKBIND has no current browser support
Need solution for browser apps.

Main goal to prevent token replay at a different endpoint. Currently at version
02.

Hannes: We have existing WG items with similar stuff. Have you considered that
work. One part is key transport, second piece is Justin’s HTTP signing document
which had challenges. What motivated to come up with a new mechanism? D: DPOP
is hopefully a simple and concise mechanism. H: The other is too. We tried to
balance in HTTP and COAP. Nat: Wondering about the relationship of this draft
ot key distribution. There is another draft I wrote called JPOP. This one looks
like more the same thing but limited to code flow. BC: DPOP came out of a
desire for a simplified concise public key mechanism at both the authz and
resource server. I think it does more with less. It has a lot of conceptual
similarities and is much more concise. H: Where it is simpler? BC: It is
simpler in key distribution because there isn’t the overhead for symmetric
keys. H:  The reason we have it is for alignment with other groups. BC: The
work here is specifically geared at work in the wild. The other specs are
underpinning for work in other groups. H:  There is historical decision to have
the work here because of the HTTP requirements (as opposed to ACE) AB: We too
find it limiting without symmetric as asymmetric can be just too slow. Does
proliferation of methods and utility outweigh the simplicity gain? JB: The
origin of this came from the security workshop specifically focused on
applications to do PoP should token binding not come to fruition.  We could use
web-crypto and create a non-exportable key in the browser. This is why there is
no support for symmetric key. Should we reconstitute that document and profile
it for this use?  We could re-factor the document to refer to other specs that
need to be resurrected if the group wants. But the issue is we have no current
method to solve the use case.  DO we address in a narrow sense or refactor to
point to the other specs? I am open MJ: Representing MS engineering teams who
did detailed analysis. 3 comments: 1. Want to use different POP keys for AT and
RT. 2. Surprised by tokens being bearer tokens and secondly being a proof
distinct from the token where the recipient checks the proof. Aaron: this has
been changed in the draft. It is no longer a bearer token 3. Despite sentiments
of the WG, we are going to use implicit for years. We would like a proposal for
using DPOP with implicit flows. Aaron: We should discuss after if the WG would
like to adopt. MJ: Want to see it minimally in a separate draft.  BC agrees.
JR: signatures are surprisingly hard. signing headers and bodies are very
important in other types of requests.  I really like this approach. But I agree
with Hannes that having a server provided symmetric key is useful. H:  none of
the documents allow server side generated keys JR: I used this pattern in the
XYZ proposal. I also didn’t use the signing draft for that because of the lack
of energy to move it forward. Message signing and key possession are both
really needed. Cavage draft seems to be generating momentum. Roman: strongly
urge the equities of other groups and surface them

Daniel - Pushed Request Objects
===============================

Create a new request object endpoint so that JAR requests can be POSTed.

Aaron: I think these are good points. This is exactly what I implemented when
justin talked about xyz

JB: JAR has been in place for a while, We left JAR open to this pattern but
didn’t include it. Had the timing been different it may have been included.

AB: This is very similar to what the device auth draft defines.  Only
difference is how the response gets back to the client. It seems wierd to
standardize two different methods to do essentially the same thing.

JR: Does not think this can be collapsed into a common model. It does need to
be its own thing. It is motivation for a next gen protocol like XYZ has.

Nat: Sending the request URI is already covered in the JAR document to keep it
small and concise.

Note: the document is not yet published to IETF as an ID.
Chairs: Should we bring this to the IETF.
General hum in favour. None against

Annabelle:  Request Signing in AWS Presented
============================================

Used for authentication, message integrity and replay protection
        Used on almost all requests use  this
        What goes into the sig – method, endpoint, path, timestamps and
        parameters  along with some
headers
        3 steps
                C14N request
                Create string to sign
       Calculate signature
        Issues:
                Versions of HTTPS changed headers and what was signed and what
                was expected

Rifaat: Nested JWT Presented
============================

Volunteers to read Phil Hunt, Nat Sakimura and Mike Jones will read it.