Subject: [Txauth] Framework vs Protocol

From: Dick Hardt <[email-masked]>
Date: Mon, 30 Dec 2019 16:20:30 -0800

I would propose that the resulting work is a protocol, and not a framework.

What is the difference? Here are my thoughts:

A framework defines a variety of ways to do each capability. A framework
usually needs a profile for two systems to interoperate. For example, OIDC
provides a number of ways to get identity data from an OP, and OAuth 2
grant types have overlap. A framework is like Perl. Lots of ways to do the
same thing, many of which are unreadable.

A protocol provides one way to do each capability.  A protocol is like
Python, there is a right way to do something.

At times a standards group will get "consensus" by not being decisive, and
including everyone's favored mechanism. In my opinion, this makes
deployments more complicated for average developers, and increases the
surface area to secure.

Do others agree with adding this as a tenet to the charter?

/Dick

Note: I'm a fan of both Perl and Python. =)

---

From: Justin Richer <[email-masked]>
Date: Tue, 31 Dec 2019 08:06:28 -0500

I agree with this. I think that with OAuth2 the extension mechanism of grant types was a decent idea, and I’ve argued that it leads to significant amounts of code-reuse from very different systems that function in very different ways. 

But I also think that what I’d like to see here, and what I’ve tried to do with XYZ, is to have one protocol that lets you branch off for different use cases where necessary but still brings you back to the same process in the end. This is one of the things I like about having the AS defined as the transaction endpoint — everyone goes to one place and sends one kind of message to start things off, and then you have everything you need to figure out where to go from there, even if it’s off-HTTP and out-of-band. 

 — Justin

> On Dec 30, 2019, at 7:20 PM, Dick Hardt <[email-masked]> wrote:
> 
> A framework defines a variety of ways to do each capability. A framework usually needs a profile for two systems to interoperate. For example, OIDC provides a number of ways to get identity data from an OP, and OAuth 2 grant types have overlap. A framework is like Perl. Lots of ways to do the same thing, many of which are unreadable.
> 
> A protocol provides one way to do each capability.  A protocol is like Python, there is a right way to do something.
> 
> At times a standards group will get "consensus" by not being decisive, and including everyone's favored mechanism. In my opinion, this makes deployments more complicated for average developers, and increases the surface area to secure.
> 
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Dick Hardt <[email-masked]>
Date: Tue, 31 Dec 2019 11:00:03 -0800

A couple questions inserted to understand what you are suggesting ...

On Tue, Dec 31, 2019 at 5:06 AM Justin Richer <[email-masked]> wrote:

> I agree with this. I think that with OAuth2 the extension mechanism of
> grant types was a decent idea, and I’ve argued that it leads to significant
> amounts of code-reuse from very different systems that function in very
> different ways.
>
> But I also think that what I’d like to see here, and what I’ve tried to do
> with XYZ, is to have one protocol that lets you branch off for different
> use cases where necessary but still brings you back to the same process in
> the end.

"... brings you back to the same process in the end." -- implies something
different than below where the process may branch off and end up in a
different place. Would you clarify what you mean?

> This is one of the things I like about having the AS defined as the
> transaction endpoint — everyone goes to one place and sends one kind of
> message to start things off, and then you have everything you need to
> figure out where to go from there, even if it’s off-HTTP and out-of-band.
>

A way to start the transaction in COAP would likely be interesting to the
constrained environment people. Would you not agree?

> > At times a standards group will get "consensus" by not being decisive,
> and including everyone's favored mechanism. In my opinion, this makes

---

From: Justin Richer <[email-masked]>
Date: Tue, 31 Dec 2019 14:12:57 -0500

Answers inline.

> On Dec 31, 2019, at 2:00 PM, Dick Hardt <[email-masked]> wrote:
> 
> On Tue, Dec 31, 2019 at 5:06 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> But I also think that what I’d like to see here, and what I’ve tried to do with XYZ, is to have one protocol that lets you branch off for different use cases where necessary but still brings you back to the same process in the end.
> 
> "... brings you back to the same process in the end." -- implies something different than below where the process may branch off and end up in a different place. Would you clarify what you mean?

I didn’t mean to imply that you’d end up somewhere else, but rather that you’d potentially take a detour through some other mechanism and come back to the same thing that you started. So I start by making an HTTP call, and then maybe I blip out a number over my speaker, or I send a DIDComm message to an agent on my device, or I redirect the user off in some browser thing — but then eventually I go back to making an HTTP call. The variability is in the middle part, where the user interaction is involved. The variability should not be in how the clients talk to other systems.

>  
> This is one of the things I like about having the AS defined as the transaction endpoint — everyone goes to one place and sends one kind of message to start things off, and then you have everything you need to figure out where to go from there, even if it’s off-HTTP and out-of-band. 
> 
> A way to start the transaction in COAP would likely be interesting to the constrained environment people. Would you not agree?

I totally agree. And they’d also want to continue and finish the transaction in COAP. And be able to do redirects using COAP principles instead of HTTP principles. And generally do things that are similar but not the same. So it turns into a different protocol with the same ideas, and I’m all for that happening — but I don’t think it’s a good idea to put it all in the same document, or to have an abstract document that everyone tries to inherit from.

We know we need and want HTTP, so to me that’s firmly in-scope. Other protocols are “wouldn’t it be nice if it did this” right now, and abstracting for something that “would be nice” leads to bad system design.

I’m not against COAP, but like with OAuth and ACE, I don’t think it’s good to try and cram them together this early. 

>  
> 
>  — Justin
> 
> > On Dec 30, 2019, at 7:20 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>

---

From: David Waite <[email-masked]>
Date: Tue, 31 Dec 2019 17:04:25 -0700

> On Dec 31, 2019, at 12:12 PM, Justin Richer <[email-masked]> wrote:

I assume still that the “transactional” nature of the protocol is that the coordinator/transaction endpoint/AS and potentially other components/endpoints are facilitating communication across software serving the different roles.

In that case, an accessing agent/client may be constrained to COAP, but the authorizing agent/interactor/external user agent could be regular HTTP. Or triggered via device or CIBA-style flows. It could also be a locally triggered user agent which is constrained to using COAP for communication and rendering CBOR-specified instructions for interaction.

Tokens might also be acquired via HTTP, but for business reasons some API are only accessible via COAP.

The ability for a client to interact with the coordinator/transaction endpoint/AS via COAP would be independent from the client ability to apply acquired tokens to COAP requests, and both of those are independent from any definition of a protocol defining user interaction via COAP/CBOR. I’d expect such a definition for user interactions for constrained clients to be out of scope, outside being allowed and an allowance for supporting multiple options for interactions.

> I’m not against COAP, but like with OAuth and ACE, I don’t think it’s good to try and cram them together this early. 

I would love the two to be kept aligned, but I neither want the requirement or impression that a conformant TXAuth implementation needs to implement COAP or to include CBOR.