Subject: Re: [Txauth] TxAuth Proposed Charter

From: Justin Richer <[email-masked]>
Date: Wed, 1 Jan 2020 17:57:52 -0500

> On Dec 31, 2019, at 3:40 PM, Dick Hardt <[email-masked]> wrote:
> 
> On Tue, Dec 31, 2019 at 11:01 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> 
>>>> 
>>>> 2. Why do you restrict this to HTTP?
>>> 
>>> Because I want us to use all of the features and benefits of HTTP instead of having to invent within-protocol functions to replicate them. I don’t want SOAP, which pretends to be transport agnostic much to its detriment. If someone wants to do OAuth 3 on not-HTTP, they can define what that looks like. This is what happened with the COAP/CORE stuff and OAuth 2.
>>> 
>>> I agree SOAP was complicated. Which features and benefits of HTTP are you wanting to use? 
>>> 
>> 
>> Well so far we’ve got headers, URLs, methods, data payload types, and the whole array of technologies that we can rely on working together along with HTTP.
>> 
>> But which ones do you want to use?
>>  
> 
> Those things that I already listed are what I want to use. I want to use the headers for sending key proofs and probably content negotiation. I want to have content negotiation so that we can have an option to use JOSE (or COSE) as the body format instead of JSON, but that function switch should come from the transport protocol (HTTP) and not something internal to our protocol. I want to be able to use redirects to get the user to interact, and get back from the interaction. I want to (eventually) do things like token revocation using a DELETE verb instead of a separate endpoint. I want to use HTTP Message Signatures (once they exist) as a key presentation mechanism. And I want our security considerations to be able to take into account the particulars of HTTP, TLS, and the like when we write them.
> 
> Thanks for clarifying. I agree that using the http content-type header, and http verbs is preferable to inventing new mechanisms.

Thanks, and those are just some examples. I want us to have all of HTTP’s features as options that we can use without reinventing them, even things I can’t think of right now.

>  
> 
>> 
>> 
>>> If it was simple to support COAP, why would we not do that?
>> 
>> Because it’s not just COAP — you’ve got a different set of assumptions for the lower layer protocols, and you’ve got lots of considerations about how the different components can talk to each other in the embedded space. 
>> 
>> You are suggesting we rule out it working with COAP in the charter, before we have even had a chance to work on it.
>> 
>> Perhaps it will be trivial to support COAP. We won't know if the charter forbids it.
> 
> If it turns out to be trivial and people want to include it and do the work here, then we could always update the charter to include it. I would rather see that than us trying to enumerate all of the target carrier mechanisms. Because if we do COAP, why not MQTT? Or BluetoothLE? 
> 
> If we include COAP, then to my mind that necessitates one of two things, if not both:
> 
> 1) We have a document that says “IF you’re doing HTTP do (A) if you’re doing COAP do (B)”
> 2) We have an “abstract” document that says “here’s this thing but for details on how to do it go read the HTTP document and/or the COAP document”, but when you read the HTTP or COAP documents, they don’t have any information about what the thing is because it’s in the abstract. 
> 
> From a developer’s perspective, I would rather have an HTTP document be self-contained, and a COAP document be self-contained. And if the two describe the same process, or one inherits from the other but says “instead of doing HTTP thing X do COAP equivalent Y”, then that’s good. 
> 
> I agree completely.
>  
> 
> But overly abstracting a system is both tempting and potentially disastrous. 
> 
> I agree. 
> 
> I align with the design tenet:
> 
> "Easy things should be easy, hard things should be possible" -- Larry Wall
> 
> If the WG has a choice between A and B, and they all other things are equal for an HTTP implementation, but B is much better for COAP, then I would suggest we choose B.
> 
> I'm not saying COAP support should be a priority, I'm saying we should not completely ignore it. 

I am in full agreement with these principles, since it would make alignment for any present or future COAP version of this protocol to be built. I think we can manage that while still focusing on an HTTP-bound process, without getting into the over-abstraction problem.

>  
> 
>>  
>> 
>> In my experience, it’s much more successful to have a protocol strongly integrated with its transport mechanism and then translated out to other mechanisms, instead of trying to come up with one universal interlingua of a protocol that just get shunted along.
>> 
>> Would you provide an example besides SOAP for this?
> 
> It’s the most egregious example that comes to mind for me, so that’s why I keep coming back to it. I also have in mind a dozen projects that never went anywhere, and nobody’s heard of, because of an outmoded effort being put into defining abstractions ahead of time in order to allow transport-agnostic messaging. 
> 
> A similar level of overly-eager abstraction went into JOSE, with the JWA document. It makes it so that JWS, JWE, and JWK make no sense without JWA, and JWA is just a collection of content that really should have been included inline with the other documents. 
> 
> I want to avoid that kind of thing.
> 
> Agreed
>  
> 
>>  
>> This is why SOAP can’t use HTTP verbs to communicate things, and why the only signatures it can use are internal. When you do that kind of system, you almost always end up having people just use it with one transport anyway, like SOAP over HTTP.
>> 
>>>  
>>> 
>>>> 
>>>> 3. Why is authentication not in scope?
>>> 
>>> It felt, to me, like that might be a bridge too far.
>>> 
>>> I disagree. But I also think that authentication is the wrong term. Identity* may be a term that maps better, as the Client is wanting to get "identity" data from the AS. 
>>> 
>>> * The identity term is super confusing, but authentication implies just knowing it is the same user, where OpenID Connect also provides claims about the user.
>> 
>> I’m coming around to this view, but I would still like it to be separate.
>> 
>> What does separate mean?
> 
> It means that the bits that say “this is how you talk about identity information in the response” are controlled by a separate spec that not everyone needs to understand. I think there are too many use cases of wanting to get API access and NOT user information for it to be a core piece. 
> 
> Some developers only care about identity. Some only care about API access. It should be easy for both.

Perhaps, but that gets us into an important question of what the result of the transaction should be. In my view, it’s delegation for access to something — some bit of information. In the OIDC model, that includes information about who the current user is. OAuth 2 always returns an access token, no matter what you do. Is this still the right model? Right now in XYZ that’s how it works, but in the pure-identity case and in Annabelle’s extended use case, that isn’t true. 

The hard question there, to me, is how do we switch that kind of behavior. I’m not fond of something like “return_type=identity” or “return_type=access_token”, since these tend to be both limiting and overbuilt at the same time. But I’ve struggled with how to manage this, and if we’re going to include identity and other use cases in the charter explicitly, then it’s something we’ll need to have a good solution for. 

>  
> 
> However, this is arguably getting into the details of how to slice up different documents, which is really a decision to be made once the WG is running and not during the charter. 
> 
> Currently, identity is not in scope of the charter, which is why I am bringing it up.

I’m currently thinking something like this for the charter text to set the right scope:

	resulting in information about the request (such as a user’s identity or current status) and/or an artifact that will allow the client to undertake the delegated action.

In other words, our focus is on the delegation protocol, not what it’s delegating to. But the ability to include information in that protocol directly is a potentially powerful pattern and we should probably include some of that in our scope. I think the identity portion can be fairly minimal, at least as a starting point.

>  
> 
>>  
>> 
>>>  
>>> If we do decide it’s in scope, then I think it should be clearly layered on top of the authorization layer. 
>>> 
>>> Being layered on top is confusing. An OpenID Connect flow where the Client receives an ID token, has not authorization, unless you are counting the UX as authorization -- but that does not seem like a layer. Would you elaborate?
>>>  
>> 
>> What you’re doing in OIDC is authorizing the application to know who you are — to get your identity information. That key insight is what makes the combination of OAuth and OIDC work as well as it does. And, importantly, once you authorize identity access, you can authorize other stuff as well.
>> 
>> 
>> As I stated, there is the UX of authorizing knowing who the user is, but there is no artifact representing that authorization as there is in OAuth -- ie there is no access token to access a resource. (yes, an access token may be used to read the user info endpoint, but that is all it can do. 
>>  
>> And it’s the “and other stuff” that people really, really, really like about OIDC. Nobody ever wants just authorization, in practice. 
>> 
>> Did you mean to say "authentication"?
>> 
>> If so, then I would posit that there are more OIDC user interactions than plain OAuth 2.0 user interactions, and that almost all of those OIDC user interactions are just logging in with Google or Facebook -- and that there is no "and other stuff".
>> 
> 
> Yes, I meant authentication, thank you. 
> 
> I’m not sure it’s true, but I’ll agree that it’s more public-facing. But even if what you posit is actually true by raw numbers, it’s not universal. In particular, there are a large number of system-to-system cases that OAuth 2 covers, which have nothing to do with identity, that we don’t want to throw out.
> 
> I'm not suggesting that those use cases should be thrown out, nor second class.

Good, because it’s important that we do think of this as more than just a pure authentication system. 

>  
> 
>> 
>>  
>>  
>> 
>>> 
>>>> 
>>>> 4. When you say "not backwards compatible with OAuth 2.0 and its extensions", do you expect to define a new standard to replace RFC 6750? Developers will have to have a new method to call APIs?
>>> 
>>> Kinda. First, it’s more 6749 that I want to step away from. But even then, I think keeping just the header version of 6750 is OK enough if someone wants to keep using that. The thing is, won’t someone seeing an OAuth 2 header assume the rest of OAuth 2 infrastructure? In some cases this won’t matter, but in many that could be really confusing. 
>>> 
>>> One of the problems, though, is that 6750 has already been clouded by things like the MTLS binding, where they use “bearer” tokens that have to be bound to the client’s certificate. So … not much of a bearer token anymore.
>>> 
>>> So, are you are you proposing that Tx have a new mechanism for API calls?
>> 
>> Yes, I think there will be new mechanisms for different kinds of key-bound tokens.
>> 
>> So are you proposing that OAuth 3.0 will not support bearer tokens?
> 
> That is not correct and I’m not sure where you got that. Bearer tokens are still useful. But they should look and behave as distinct from sender-constrained tokens. But ultimately we can tell the client how the token gets used, as below.
> 
> It was not clear from your response, as a new mechanism could mean that the old one is not used anymore.
> 
> To clarify, you expect there will be additional mechanisms.

Correct. I would expect us to either redefine or re-use bearer tokens a la 6750 in some capacity but also have other presentation mechanism, like using HTTP Signatures (once Annabelle and my draft is real) and MTLS binding (like the OAuth MTLS binding). 

Thanks again for the great discussion! It’s important to get these details out where they’re readable.

 — Justin

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 3 Jan 2020 00:45:46 +0000

My feeling is that the charter should read more like a problem statement than a solution proposal. I think we’re on the same page there. However, the current text doesn’t adhere to this:

  *   It mandates a transactional protocol. While this is the approach we’re starting from, there is no guarantee that it is the correct one, and we shouldn’t box ourselves into it.
  *   It refers to the authorization server. While this role tends to be central to our solutions, it’s not clear to me that it is an inherent part of the problem statement.

–
Annabelle Richard Backman
AWS Identity

From: Justin Richer <[email-masked]>
Date: Tuesday, December 24, 2019 at 4:11 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Dick Hardt <[email-masked]>, Eve Maler <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: Re: [Txauth] TxAuth Proposed Charter

I don’t think we should write the charter with a specific solution in mind, but instead describing the problems that we want to solve with a standard. The “with a standard” is important here as not every aspect is going to need a standard specification, only the parts where we expect communication and interoperability between implementations, right?

I would say that rather the charter should be more general in describing the purpose and not putting things :out: of scope. It might very well be that the deployment you’re describing is an optimization, but if it makes sense within the bounds of the work, even if the details are described in their own spec (or not in a spec at all, if we decide that’s one of the “under the hood” aspects), then that’s OK. I do agree that what’s really important here is having an idea of what the different moving parts are, at least to start. Any proposed ideas on how to describe this without getting into prescriptive deployment details?

 — Justin

On Dec 23, 2019, at 6:22 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

The point is, I might want my tokens to be signed using keys that my TX Endpoint does not have access to. E.g., my token issuer signs tokens with key A and my TX Endpoint signs HTTP response messages with key B, neither system has access to the other key, and tokens signed by key B are rejected by RSes. This requires the working group to understand that trust boundaries may exist between the different components implementing portions of “AS” behavior. If this isn’t understood, then if/when I bring up this use case, I’m going to be told “there are no trust boundaries within an AS, so what you’re describing isn’t an AS anymore, and not in scope per the charter.”

I’m sensitive to the desire to not overcomplicate things. The scenario I’m describing is unusual, and probably not what we should optimize the protocol for (though that could always change). But we’re talking about charter, not protocol. The charter can be as detailed and nuanced as it needs to be to properly describe what we are setting out to accomplish.

–
Annabelle Richard Backman
AWS Identity

From: Justin Richer <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 23, 2019 at 1:57 PM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Cc: Dick Hardt <[email-masked]<mailto:[email-masked]>>, Eve Maler <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Txauth] TxAuth Proposed Charter

So the thing is, I don’t think you need a single JWKS URI anymore anyway. You’d have one associated with the TxEndpoint, if you’ve got signed tokens that you need to validate separately. And if you’re doing signed user assertions, you’d have a different one identified in the assertion (either directly or via an issuer-discovery mechanism). Ultimately the client is going to care about one and the RS about another so it’s fine that they’re different. We get to define what that looks like.

On the surface I’m OK with a decomposed AS, to some extent, but only if there are very, very clear boundaries about what the individual roles are. And the more roles we make, the more we have to define what the communication points are in between them. Maybe “AS” is too all-encompassing of a role now, but I’m not yet convinced that’s true in practice, and I do want someone to be able to deploy this by having all the “server” side functionalities running out of a single, simple box. That might be a case of that single box needing to play multiple roles, and that’s OK, but we need to be clear on what kinds of optimizations are allowable in cases like that.

I do think there’s precedent in asking this question though, since between OAuth 1 and 2 we split the “server” into “AS and RS”. OAuth 2 famously didn’t define a connection point between them until much later (JWT and Introspection), but that pattern seems to have mostly worked.

 — Justin

On Dec 22, 2019, at 11:52 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

My example demonstrates an architecture where the TX Endpoint, authentication system, and token issuer aren’t simply different micro services, they’re completely independent systems in different trust boundaries, possibly have different domains and different keys. This has implications for protocol design. For example, it would no longer be sufficient to have a single jwks_uri, as OAuth 2.0 has.

If we want to support this kind of “decomposed AS” model, then we need to make sure that’s supported by the charter and keep it in mind as we design the protocol. We can also decide it is out of scope, but we should be intentional about that decision.

To my mind, this role decomposition is the next logical step after the channel decomposition that TxAuth already does. I see a lot of potential in it and think we should at minimum avoid closing the door on it.

On Dec 22, 2019, at 5:35 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
I think you’re conflating the roles that different components play, in regard to the other components, with the potential deployment of those components. The spec needs to be written in terms of the roles. While the roles do need to consider what potential deployments might be, it’s important that we write things in in terms of how they interact with each other and not in terms of how they might look under the covers.

So from the clients perspective, the TX Endpoint :is: the AS. The client doesn’t care that it’s a “glorified message queue” or if it’s a massive server farm. The client doesn’t care if there’s a TLS reverse proxy or if it’s talking directly to the application layer. The only thing the client cares about is if the TX Endpoint does the things that a TX Endpoint is supposed to do, and we define that to be the function of the AS.

What’s important in your scenario below is that the client would have to talk to the RS first every time. That’s one of the problems that UMA has, and I think something we should avoid. I think RS-first is an interesting pattern but AS-first ought to drive this.

With your hypothetical layout below, it really sounds like the TX Endpoint is a function of the IDP, which is fine. The client doesn’t care that it’s deployed using some externalized cloud service. The only weird thing going on is the push from the AS back to the client. The client would need to register that with the AS (or through the AS more specifically) as part of its transaction request. This would be part of its interaction mechanism, because “how you get messages and updates back to the client” is part of the interaction model.

So for an RS-first transaction, the client calls the RS:

GET /foo

The RS returns a resource handle, but the client doesn’t care where that came from. The RS could talk to the AS to get it. Probably a new endpoint of some kind, can probably use the same kinds of key binding that the TX Endpoint has. Or the RS can make one up that the TX Endpoint can recognize. Or it calls the IdP to get one. The client doesn’t care, and that’s the key point.

WWW-Authenticate tx_endpoint=“http://server//tx<http://server%EF%BF%BD/tx>” resource: “asdf1234”

The client calls the TX endpoint like a normal transaction:

POST /tx

{
  resources: [ “asdf1234” ],
  interact: {
    redirect: true,
    push: “http://client/push/9876”
  }
}

The AS (which is to say the TX Endpoint) tells the client to send the user agent to the IdP

{
  interact_url: “http://idp/login”,
  handle: { value: “hjkl”, type: bearer }
}

Now the client could poll the TX Endpoint but it could also just sit and wait for an update to be pushed in.

There are probably things that need to be tied together for this to be secure, but I think the basic pattern still fits. Importantly, the client doesn’t care whereby of that stuff came from — as far as it’s concerned, it’s talking to the AS.

Remember, the “AS” is a logical construct, not a physical one. Just like the “client” could be a cluster of applications and the “RS” could be a suite of APIs tied behind a gateway.

 — Justin

On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 21, 2019, at 4:42 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

Even if the client starts at the RS, the client still has to go talk to the AS. I haven’t built this out, but I see it working somewhat like UMA. In XYZ’s terms:

1. Client calls the RS trying to Do A Thing
2. RS calls the AS requesting a Resource Handle (because that’s what the RS represents, resources) — at least good enough to cover what the client tried to do, could be more
3. RS gives the Resource Handle and AS Transaction Endpoint back to the client
4. Client calls the AS Transaction Endpoint to start a transaction, includes the Resource Handle as part of its request (note: doesn’t have to be the whole resource section, client can add stuff)
5. Process continues as normal

It depends on what you consider the “AS”. Consider the following hypothetical architecture:

• The RS, client, and tx endpoint are on the public Internet.
• The tx endpoint returns interaction urls that point to an IdP that is inaccessible from the public Internet.
• The user agent can reach the IdP, but none of the other systems can.
• When the UA is redirected to the IdP, the IdP calls the tx endpoint system to retrieve transaction details.
• When authorization is granted, the IdP pushes artifacts directly to an endpoint provided by the client.

In this example, the client only interacts with the RS and the tx endpoint. It seems odd to me to consider the system hosting the tx endpoint to be the AS (or at least part of the AS), as its a glorified message queue with essentially no authority in this architecture.

We could go a step further and remove the client’s interaction with the tx endpoint by having the RS return the interaction url directly (you’d need to secure the client nonce if you want to hide it from the RS, but that’s not that hard).

Is the meaning of “authorization server” (or the phrase “through an authorization server”) flexible enough to accommodate these cases? Or are they considered out of scope for TxAuth?

 — Justin

As I said, maybe I’m being too literal.

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=81127a9d-0641-423c-be77-812070241103]ᐧ
On Fri, Dec 20, 2019 at 5:08 PM Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
I’m not sure if this is what Eve had in mind, but consider an automated system in an enterprise context that has been authorized by an administrator. The automated system isn’t acting as or on behalf of the administrator, and the administrator hasn’t “delegated access”; they’ve granted access, just as they do when they assign permissions to users/groups/roles/etc.
Maybe I’m being too literal, but “through an authorization server” in paragraph 1 implies a specific context/information/request flow to me. Given that one of TxAuth’s features is decoupling the different communication channels, we should not suggest that the client or authorizing party is directly interacting with the AS.

–
Annabelle Richard Backman
AWS Identity

From: Txauth <[email-masked]<mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked]<mailto:[email-masked]>>
Date: Friday, December 20, 2019 at 4:14 PM
To: Eve Maler <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Justin Richer <[email-masked]<mailto:[email-masked]>>, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Txauth] TxAuth Proposed Charter

Eve: do you not think the software client is acting on behalf of some party? Or do you think that software always is acting on behalf of some party, and the mentioned phrase is redundant?

Justin: a couple questions

1. What is meant by "Delegation between multiple users" ?

On Fri, Dec 20, 2019 at 3:27 PM Eve Maler <[email-masked]<mailto:[email-masked]>> wrote:
Re “to a software client _acting on behalf of an authorizing party_”: There is a whole lot of philosophy behind whom the delegated access is performed on behalf of, unless the scenario is single-user or some "act as" semantic is spelled out on the wire. Does it need to be stated here? What's the consequence if the highlighted phrase were removed?
Eve Maler (sent from my iPad) | cell +1 425 345 6756

On Dec 20, 2019, at 4:34 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

As discussed in Singapore, no matter what forum TxAuth takes, its work will require a new charter. With that in mind, I’ve taken a bit of time to put together a proposed charter text for the TxAuth work:

This group is chartered to develop a next-generation transactional authorization and delegation protocol for HTTP-based APIs and their clients. These transactions will allow an authorizing party to delegate a right of access for an API or set of APIs through an authorization server to a software client acting on behalf of an authorizing party.

The group will deliver a protocol specification detailing how a client can request and obtain delegated access, how an authorization server can provide delegated access, how an authorized party can authorize delegated access, and how that authorized access can be communicated to the resources being protected. These actions will be connected through an explicit transaction between the client and authorization server, resulting in an artifact that will allow the client to undertake the delegated action.

Additionally, the delegation process will allow for:
- Fine-grained specification of resource access
- Delegation between multiple users
- Web, mobile, single-page, and other client applications

The group will define extension points for this protocol to allow for flexibility in areas including:

- Cryptographic agility for keys, message signatures, and proof of possession
- User interaction mechanisms including web and non-web methods
- Token presentation mechanisms and key bindings

The artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 and its extensions.

While this work could be done in within the OAuth working group, I now believe that it should be done in a new working group, and that we should try to get that working group up and running prior to the Vancouver meeting in March.. I think this group should stay here on the TxAuth list, and it’s my suggestion that the resulting work be called OAuth 3.0.

Why a new group? I think that the OAuth working group should remain focused on extending, patching, and adapting OAuth 2.0 to a changing world. I plan to be engaged in both groups, and I know most of you are as well, but that’s not universal. Since OAuth 2.0 is so established already, there are a LOT of people who aren’t going to be interested in something new any time soon. But on the other hand, there are a number of people for whom OAuth 2.0 does not work, or is at the very least a poor fit, and we’ll want to bring them in at this early stage. So even with significant overlap, I think there’s enough disconnect in the community from both sides that warrants a new group. In addition, I think this is a big enough piece of work that it’s simply too much for the OAuth working group to be able to focus on. We wouldn’t be able to get additional meeting time, and OAuth already has trouble fitting into its two meeting slots as it is.

I’ve published a blog post detailing more of my rationale:

https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working-group-d6229ba8e36?

Please suggest changes to the proposed charter text above. It’s my hope that we can get the chartering process started.

 — Justin
--
Txauth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 3 Jan 2020 01:37:26 +0000

> In other words, our focus is on the delegation protocol, not what it’s delegating to. But the ability to include information in that protocol directly is a potentially powerful pattern and we shoul…

This treats identity as a special case resource where the transaction endpoint doubles as the resource server. OIDC does the same thing, so it’s not unprecedented. Are you proposing that we support this model only for identity, or for arbitrary resources as well? If it’s just supported for identity, we need to make the case for why identity deserves special treatment. I.e., what makes identity special enough to warrant being able to retrieve it directly from the transaction endpoint, and what makes us certain that no other resources meet those requirements?

–

From: Txauth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Wednesday, January 1, 2020 at 2:58 PM
To: Dick Hardt <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Eve Maler <[email-masked]>, "[email-masked]" <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: Re: [Txauth] TxAuth Proposed Charter

On Dec 31, 2019, at 3:40 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Dec 31, 2019 at 11:01 AM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

I agree completely.

I agree.

Agreed

What does separate mean?

 — Justin

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 03 Jan 2020 22:21:35 +0200

I strongly agree with Justin’s plan, and suggest that we revisit the name a year after chartering this work.

Naming *is* important. The OAuth3 name indicates to the market that this is the next iteration of OAuth2, regardless of technical backward compatibility. By “next iteration” I mean that most of the OAuth2 use cases are covered, and the new protocol is “better” than the old one in some sense.

In a year we will be able to make a call whether there is good coverage of use cases with this protocol, and then we will need to reach community consensus that this is the next protocol iteration, where the community includes some people who will not deploy it for years to come.

Thanks,

                Yaron

From: Justin Richer <[email-masked]>
Date: Tuesday, December 31, 2019 at 20:37
To: Dick Hardt <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Aaron Parecki <[email-masked]>, Yaron Sheffer <[email-masked]>, Benjamin Kaduk <[email-masked]>, Brian Campbell <[email-masked]>, <[email-masked]>
Subject: Re: [Txauth] TxAuth Proposed Charter

And just to reiterate a previous point — as much as I want to make the case for calling this work OAuth 3, it’s not something I’m going to die for. The work is way more important than the name. 

So with that, I would propose that we basically punt on naming things until that becomes important. I say we name both the working group and the first document “TxAuth”, and keep this mailing list as its base.

If the working group decides in a couple years that this really should be renamed, we can do that. It’s happened before — and again I’m calling to the model of HTTP/3. It started as QUIC in the QUIC working group, and a year ago the QUIC working group decided to rename it to HTTP/3, with the coordination and blessing of the HTTP working group. Once QUIC group winds down, the HTTP/3 protocol will come under the stewardship of the HTTP working group. I can easily see a similar pattern happening here, where we create TxAuth and eventually it gets handed over to the OAuth WG.

 — Justin

On Dec 31, 2019, at 8:09 AM, Justin Richer <[email-masked]> wrote:

My understanding is that HTTP3 is not backwards compatible, since QUIC was built on UDP from the start and the considerations are pretty different from TCP there. 

I don’t think the safe answer is “do nothing” today because there is a large and vibrant community around OAuth 2. The safe answer is to deploy something that solves your problems.

I think that we’re going to have the imaging issue vis a vis “replacing OAuth 2” whether we call this OAuth 3 or TxAuth or whatever. Truth is for some people we will be replacing OAuth 2, and some people will be throwing out their OAuth 2 implementations (if we’re successful). But that’s the cost of tracking new technology, and it’s pretty clear to me that this work has a long ways to go.

 — Justin

On Dec 30, 2019, at 6:25 PM, Dick Hardt <[email-masked]> wrote:

I significant difference in this case is that OAuth 3 is NOT backward compatible with OAuth 2.

HTTP 2 was backwards compatible, as is HTTP 3 from what I understand.

This has enterprises question what they should do, and the safe answer is do nothing. I think this is what Brian was getting at on confusion. People are confused on what they should do. OAuth 3 not being backward compatible implies work done with OAuth 2 may have to be thrown away.

On Sat, Dec 28, 2019 at 9:07 AM Justin Richer <[email-masked]> wrote:

This is going to be the case whatever we call this new work. Progress is going to continue to happen, and if a large enterprise decides to wait for the new shiny thing 3 years from now, then that’s on them. 

In my experience, it’s more likely that a large enterprise is going to shy away from the new shiny thing and go with what they can buy in a supported package off the shelf. And I think that’s the kind of timescale that’s going to drive most of the developers decisions around whether to track the new work or use what’s out there — they need to ask “what do I need?” And “when do I need it?”

But these are :always: the questions that you need to ask when starting a project and choosing technologies. 

I still contend that the name OAuth 3 does a better job at communicating what’s going on here.

 — Justin

On Dec 27, 2019, at 1:27 PM, Dick Hardt <[email-masked]> wrote:

I agree with Brian. Developers such as large enterprise customers are going to be confused when they hear there is an OAuth 3 in the works. Some will push pause on projects because they worry that it will be outdated when it is released. They won't know which to deploy, even though OAuth 3 is not available. 

Also, if what we are working on includes authentication / identity -- it no longer is just delegated authorization

See inline comments below.

On Tue, Dec 24, 2019 at 4:22 PM Justin Richer <[email-masked]> wrote:

Brian, I hear what you’re saying, but I disagree completely.

Who would be confused by seeing a major revision to an existing protocol that worked in a different way and did the same things but also new things? That happens all the time.

And it causes market confusion all the time. Conservative organizations stop doing things when it is not clear what the future will be.

Was there significant confusion between OAuth 1 and 2, enough to hamper adoption of either? For the people who deeply invested in OAuth 1 and didn’t need or want the OAuth 2 newness, they stuck with it (see: twitter). 

Twitter stuck with OAuth 1 because they did not like bearer tokens. 

Yes, there was lots of confusion between OAuth 1 and 2. Erin did not want what became OAuth 2 to be called OAuth because of the confusion. Hence it was called WRAP early. The actual name of the WG is "Web Authorization Protocol"

Was OpenID Connect a major disservice to OpenID 2? It was a disruption, for sure, but people transitioned where it made sense for them, and in many cases that took years of dual-deployment and transition. 

The work that was being done on OpenID 3 was killed because a large platform company that starts with G did not want to confuse their customers about a new version.

I see us walking along the same kind of path here, nearly a decade later. That’s why I think OAuth 3 makes sense as a name for the output of this work. Or at the very least, for the core delegation protocol portion of whatever we make. I think it sends the right message to implementers and developers: the community that knows and understands OAuth 2 is working on the next version of that thing, so when it’s ready, maybe you should look at it. Until it’s done, and for a long time after, OAuth 2 is still going to be there and be the right answer. 

I agree that people may be confused if it is called something else that OAuth, but if it is broader than OAuth, then that is confusing as well.

The name isn’t a hill I’m committed to dying alone on, but I think it sends a :bad: message if we call it something new entirely. Namely, that we think people :should: abandon the entire world of OAuth, all of its ideas and implementations. That’s not what we’re doing with this design, it’s an evolution as I see things. And as an evolution, a new major revision number makes sense.

 — Justin

On Dec 24, 2019, at 9:54 AM, Brian Campbell <[email-masked]> wrote:

Naming any prospective resulting work here "OAuth 3.0" would significantly exacerbate confusion in the whole space and would be a major disservice to the broader community. 

On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki <[email-masked]> wrote:

I definitely am not trying to discuss specifics of *how* authentication should be included right now, but I just want to make sure it's included in the charter so that we can actually talk about it and it won't be "out of scope" when we eventually do talk about the specifics.

Aaron

On Mon, Dec 23, 2019 at 1:51 PM Justin Richer <[email-masked]> wrote:

I’m fine with it being in charter but I do think it should be a clearly separate layer, much like OIDC/Facebook Connect/GitHub Login/etc are with OAuth today. In all of these the authorization is first, and I think that’s the right pattern. So if we do take it on we’ll just need to be careful how it’s structured in with everything else. Otherwise, I think the authentication side can quickly overwhelm and drag down the authorization side.

Good news: A lot of the additional stuff in OIDC is there to patch holes in core OAuth in a common fashion, and we’ll at least be in a position to not have to do that again. 

 — Justin

On Dec 22, 2019, at 10:46 PM, Aaron Parecki <[email-masked]> wrote:

I do think authentication should be part of the charter from the outset. Frankly the fact that authentication is intentionally left out of OAuth and has to be bolted on to the side via OpenID Connect is one of the exact reasons people get confused about the whole space to begin with. 

It's a relatively minor addition to the existing proposed spec to make it useful as a minimum viable authentication solution, and I'd like to see that be addressed at the beginning of this work.

I think we can do this in a smart way and that authentication should be included in the charter.

Aaron

 

On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer <[email-masked]> wrote:

Hi Justin,

I think the charter should mention target use cases. For example, “all use cases supported by OAuth 2 will be supported by the new protocol” or “the protocol will support at least use cases X and Y”.

And given the importance of OIDC, we could say something like: “The protocol will allow future extension to support authentication, in an analogous way to OpenID Connect. However authentication is explicitly not part of the initial scope.”

Thanks,

                Yaron

From: Txauth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Saturday, December 21, 2019 at 00:34
To: <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: [Txauth] TxAuth Proposed Charter

Hi all,

While this work could be done in within the OAuth working group, I now believe that it should be done in a new working group, and that we should try to get that working group up and running prior to the Vancouver meeting in March. I think this group should stay here on the TxAuth list, and it’s my suggestion that the resulting work be called OAuth 3.0. 

https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working-group-d6229ba8e36?

 — Justin

-- Txauth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/txauth 

-- 
Txauth mailing list
[email-masked]

-- 

----

Aaron Parecki

aaronparecki.com

@aaronpk

-- 

----

Aaron Parecki

aaronparecki.com

@aaronpk

-- 
Txauth mailing list
[email-masked]

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

-- 
Txauth mailing list
[email-masked]

-- 
Txauth mailing list
[email-masked]