Minutes for OAUTH at IETF-88
minutes-88-oauth-1

OAUTH WG - IETF 88

PARTICIPANTS
------------
* Anthony Nadlin (AN)
* Brian Campbell (BN)
* Derek Atkins (DA)
* John Bradley (JB)
* Justin Richer (JR)
* Mike Jones (MJ)
* Nat Sakamura (NS)
* Phil Hunt (PH)
* Prateek Mishra (PM)
* Stephen Farrell (SF)
* Tim Bray (TB)
* Torsten Lodderstedt (TL)
* Matt Miller (MM)

Draft Statuses
--------------

* draft-ietf-oauth-jwt-bearer :: Mike Jones is working to update from feedback

* PH : At the end of Berlin, presented auth draft.  Some changes to
align with OpenID, but waiting on recharter discussion.  Would like
feedback.
* NS : What is a good time to talk about recharter?
* DA : Looks to AD -- let's finish some of the work we've got, then we
can talk about adding more work.
* SF : I don't think I saw discussion about recharter, and we have a
number of knotty problems that need to be resolved first.
* PM : I am confused about where we are with the SAML and assertions dtrafts?
* DA : Waiting on Barry and Hannes to finish reviews -- can't do
anything until they're done.
* PM : Are there any substantive problems?
* DA : None that I'm aware of
* SF : Sometimes there's too much process in the IESG, so we're kind
of waiting on the WG to finish.
* NS : On recharter, should we postpone all the discussion on new
documents until we get these other things done?  I am puzzled by all
the -00's while there's WG items to finish.
* DA : These new drafts are toward the current charter items.
* BN : My understanding -- came back from IESG after 86, and made
significant changes.  Now waiting on Hannes and other feedback.
* DA : Hannes has been very busy with other activities, and can't get
to these right now.  We are waiting on Hannes right now.

* JR : I suggest we fold stateless-client into dynamic registration.

Proof of Possession (Anthony Nadlin)
------------------------------------

* PH : IIRC the MAC spec was folding in HotK, and we thought symmetric
was sufficient.
* JR : To follow up, we had decided that we wanted to do MAC
(symmetric), but if we could do asymmetric as easily then we would.
* JB : There was a feeling at the time that asymmetric with channel
binding was too complicated, so we started off with the simplest
(symmetric).  I just sent a message to the list about why symmetric
keys are bad.  One advantage of asymmetric keys is that people do the
right thing more often.
* PM : Are you referencing a draft?
* AN : Yes, there's a HotK draft (expired), that we think should be
updated to talk about asymmetric keys.
* PM : ANd you're proposing a new approach?
* AN : No, I'm proposing we move it into the WG draft.
* PH : On TLS channel binding, that was something exploring a new
draft.  It was interesting, but introduced a bunch of new questions.
* AN : Channel binding was one approach, but there are others.  I am
proposing we update the HotK draft to talk about a couple of other
ways.
* JR : One feature from OAuth1 and other drafts, is to optionally sign
parts of the HTTP message in addition to just the token.
* AN : It gets into some issues, but if you have a specific use-case
then we should talk about it.
* JR : I brought them up on the list and in the call, but I can
reiterate them again.  And I think we can layer them into the JWT
approach.
* AN : But it's a different signature
* JR : It's actually not -- it's just JWS.

* MJ : I lost track -- does this require rechartering, and is
recharting in flight?
* DA : I don't think this draft requires rechartering, and we do not
have a recharting in flight
* TL : Did you want to remove symmetric?
* NA : No, we just wanted to update the asymmetric part.

ActAs/OnBefalfOf (Mike Jones)
-----------------------------

* TL : Clarifying question: is the security token an assertion?
* MJ : Yes, it's functionally equivalent.
* TL : I suggest you use assertion.  Also, is this meant to be a
token, or an assertion?
* MJ : It's an assertion. It might be used as an access token, but
that is outside the scope of this.
* TL : I suggest this go to another endpoint because it's not
compliant to the current semantics
* JR : I would like to see an alignment or clear delineation between
this approach and where tokens have been used to get other tokens.
I'm not going so far as to requiring a different endpoint, but I would
like an alignment or delineation.
* DA : What's the difference between of an assertion and a token?
* JR : A token is completely opague to the client.
* MJ : I take your point on comparing this to token-in/token-out approaches
* PM : Is this a profile of the assertion draft?
* MJ : No
* PM : And this is not a profile is because this is returning an assertion?
* MJ : There are several reasons -- you can use an assertion to get
access tokens or authorization codes. We didn't want to jam a third
thing into the assertions draft.
* PM : I would like to see some standardization in this space
* JB : I agree that I think this is a good pattern.  I would have said
that these tokens are encrypted for the intended audience, but are
most likely opaque to the client.  The intent is not to send
structured tokens to the client, but to send structured tokens to the
recipients through the client.  It might be similar enough to
overload, but we need to think carefully about it.
* NS I think this support is for a very important use-cases.  What's
the relationship between OBO and OpenID-Connect ?
* MJ : One is used as a client id for openid-connect, and one might be
a security token for some other party.
* NS : Where would this fall within our current charter?
* DA : I don't think this falls within the current charter.
* AN : I would also want to look at it as pure token exchanges.  The
current specs are rather ambiguous about what exactly is returned.
I'm not opposed with the endpoint sending back specific token types.
Also, this pattern matches what a lot of enterprises do today, so I
think we need to extend this into OAuth.
* TL : Why does this need to return structured tokens? I think the
structured tokens limits us too much.
* MJ : That might be, but the structure allows us to verify the identity.
* JB : Note that an opaque token could be a reference, or it could be
a structured token.
* MJ : To be clear, I didn't talk about token references at all.
* JB : Token references is also a legitimate design pattern.  I have
customers that can't use structured tokens.
* MJ : OAuth already has artifacts -- authorization codes and access tokens
* TL : WHo is the recipient?
* MJ : THat is out of scope
* TL : I suggest comparing this to the token exchange approach.  I
think this is very similar to the other approach.
* MJ : I wrote this to get the discussion going, which it seems to do.
But I want to know what the group wants to do next.
* DA : I think we should take this to the list, and see if the WG
wants to recharter to take on this work.
* PH : I would like to see a fresh perspective on the use-case, since
REST is point-to-point and more immediately needed, while WS-Trust is
more end-to-end and not really needed.

DynReg
------

* MJ : Some times you don't want to register at all.  Purpose of
registration is to get a client id.  You could define ways to generate
client ids without registering.  Is that what you were getting at.
* JR: The answer is yes.
* JR : How I get the client id is independent.  As a consequence we
have two RFCs for that.  We can get tokens in a number of different
ways.
* AN : Client doesn't know how to encode things.
* JR : Assertions don't give you a client id.
* PH : Are we addressing all the use cases?  Transient use case;
software statement which can be given out-of-band.  Put in an
identifier and that would be known to the end-point.  Software state
is a known profile.
* JR : Client id is public information, bad idea for authentication
purposes.  Use only as a point of reference.  Still useful for
authorization server w/o having to reregister all the time.
* MM : I'm going to needs this.  We want to handle stateless client
really well.  Boot strap to oauth.  If we can keep common ground that
would be benefical for 3rd party clients.  Need a standardized way of
getting them.  Not concerned of what's in them.
* JR : Original use case for the client.  Server wants to know what's in them.
* MM : Important for clients on how to get them.
* JR : Gives you reusable components.
* JB : Can escalate privileges.  We have a number of ways for doing
client credentials.  We identify through some credential or redirect.
We can't blow a hole in our security model.  We have a client with an
opaque token for reference or assertion.  What are we attempting to
gaurantee registration identification.  This is core to our security
model.  Have to allow for self assertion.
* JR : I can make a client id, the server has to be very careful.  The
purpose of registration; there are two aspects; 1. the authz server
needs an identifier 2. a client talks to multiple authz servers in
different security domain.  Dyn reg needs to solve both problems.
* MJ : Tony said: We don't want to jam structed identifiers in the
enterprise.  Authz server chooses to issue structured identifier or
authz server could advertize client identification structures.  These
are two separate choices for authz servers.  We can define a simple
registration structure and a separate structure for the
non-registration case.
* PH : Three registration modes; wanted to flesh out the various client types.
* MM : The assertion that non-http client don't use URIs is false.
Whatever structure we use, the bare minimums needs to be defined.
* PH : For the client perspective, it needs to be consistent.
* MM : We need to be consistent for the protocol used.
* JR : Everything is optional -- hand waving.  Send these fields ever
time using this protocol.  Connect does this already.
* JB : Most protocols use URIs.  Leave other options of identifying the client.
* MM : There is an HTTP response with a location, it uses a URI.  URI
location doesn't have to be HTTP or HTTPs.
* TB : Lots of use cases that should be considered, but are not being
considered.
* JR : Cred uid moved to optional.
* MM : Dyn 14 works for me right now, could have clarifications on
client implementations, etc.
* TB : There are lots of use cases for which dynreg-14 works pretty
well, and I’m a little sorry to see those being pushed on the shelf
while the WG addresses more.
* MJ : Support separation out core registration from the ability to
update state.
* AN : We've come up alternatives that solves are use cases.  There
are scalability issues with dyn 14.
* PH : What are the use cases for a management API?  It is not clear.

Registration (Phil Hunt)
------------

* JR : I think a large part of the mismatch in the usefulness of a
management API.  If the client software is very fixed, then you don't
need a management API.  If it's more ephemeral, then management makes
sense.
* PH : Is it something really worth having a protocl for?
* JR : If you have a manual admin process, then you don't need an
API. But if you don't have an administrative step, then that's where
it makes sense.
* PH : If you allow your clients to be anything they want at any time,
why would you let clients do this over protocol?
* JR: You are conflating many different ascpects.  Hackers aren't just
going to do whatever they want, because presumably we have endpoints
that require authentication/authorization.

* JR : In the association draft, the token-in is the software
statement, correct?
* PH : Correct
* JR : So changing the token-out is changing the software statement then?
* PH : No, you can ask for the token type separate.
* JR : So if your model calls for PKI, or etc, then you could do that
without changing anything...?
* JR : I see associations and dynreg as the same thing.  What gets
passed in is slightly different, but what gets passed out is what the
client needs to know.  With that, you could very easily send out a
client_secret, or an assertion, or a certain token, without changing
the registration at all.
* PH : We did this move the ball forward thing.  What we have today is
a password that has to be stored.
* JR : Passwords don't have to be stateful
* PH : Why do you need it then?
* JR : Because that's how OAuth works today
* PH : It's not.  Don't we want to move the ball forward?
* JR : What you have could spit out a client secret or an assertion.
Clients today assume HTTP with headers.
* JR : One more point about client associations can't be reasonably
implemented today, because the token endpoint takes in a set of form
parameters (one of them being grant_type).  Client association uses
the same field name expressed in a JSON object, and that's fine
because it's in the context of the JSON object.  We used to have form
parameter for dynreg, and decided to move to JSON.
* JR : In order for my existing endpoints to implement this, I would
need to examine the grant_type to determine if I am parsing form
params or JSON.
* BN (via JR) : He believed that JSON in was a confused portion of the
client association.
* JR : As an implementer, I know that I cannot do client associations
* PH : Whether we have consensus or not, we could merge the specs.
* JR : From my perspective, I don't think we can do client
associations via the token endpoint; it would need to be a new
endpoint.
* PH : You said that a software statement is not possible.
* JR : I have been supportive of software statement from the start.
* PH : I don't see a point in closed loophole, except for Torsten's
point about a token endpoint being just a token endpoint.  We are
defining a new profile, not a new endpoint.
* JR : And my point, I don't think this is implementable as it is
currently written.  That said, parts about validating the registration
should be merged in.
* PH : Your point is well made.
* JR : The Connect API says that the token endpoint could be the same
as your registration endpoint, if you can handle it.  What I want is
the abiity to separate the functionality based on the endpoint.  If
you want to co-host it, then go ahead.  but I think it's important not
to require it.
* PM : One point - just because draft allows for a client secret part
of the spec, and human beings need passwords, but we need to be
careful for using these for other functions because of the Lowest
Common Denominator factor.
* PM : Second point - what kind of token endpoint is appropriate, and
that seems like a solvable issue.
* PH : I say it doesn't matter, but there is merit to re-using the
token endpoint.  We do it all over the place.
* PM : OK, if the current RFC doesn't accommodate that, then we need
to address that.
* PH : Everything is basically doing something-in to something-out.
* JB : I think your presentation was lacking what you were proposing
to merge, and some of us are confused.
* PH : I was working with an open format discussion, and that was not
clear from the slides.
* JB : One thing that is similar is the software statement and my
draft about a structured client_id.  It was not specific to dynreg-14,
it could be used with client assocications.  You just need to get this
to the authorization server, either with storing state or through the
client id.  Possibly how you create the JSON object and possibly sign
it could be agreed on.
* PH : One of the things I'm trying to get to is consistent use of the
software statement.
* JB : Having a client authenticate itself with an assertion is not
really different from authenticating with a password.
* PH : There is a differece. Dynamic registration its a registration
step not an authentication step.  You could try to track that the
client returned again, and is that a worthwhile thing, I'm not sure.
* JB : And it depends on what your notion of a transient client is.
Just because it's Javascript running in a browser might not mean there
isn't a central authority.

* JB : Can we reach consensus on the following?:
* JB : Perhaps we have some convergence on the stateless client
parameters and software statements.  Exactly what the parameters and
the software statement there is some possible agreement.  Exactly what
endpoint is doing it might require extra shoehorning.  The token
endpoint isn't the one actually protected by OAuth.
* PH : Does registration itself need to be protected.  Which gets back
to if we need a registration token.
* PH : One of the reasons that I put software statement as a separate
parameter is to try to not conflate all of this together.
* JB : I think there are a couple of issues to sort out, and the
sooner it happens the better.
* AN : There is a lot of abuse about the endpoints today.  The spec
doesn't clear state that the endpoint only return one thing, and some
things have implemented them together because they don't want them
separate
* TL : As an outside observer, I find this discussion very useful.  I
propose we really nail down the pros/cons about the approaches in
order to move forward.
* PH : It sounds like you say it's a more core issue.
* DA : I encourage people continue to discuss this to keep making
progress, but we haven't yet come to a conclusion.
* Lucy Lynch : I just want to +1 all of this.  We originally separated
because we couldn't agree on it.  I agree this is a realy important
dialog, and I'm not sure anyone really understands what it means.