Re: [Txauth] Call for charter consensus - TxAuth WG

[Fabien Imbault <[e-mail]>]

Hi Justin,

Thanks, I think your answer makes perfect sense and clarifies better the
intent. I'm good with that and certainly agree not to over-engineer.
I'm available to help on the current WG, and later on for
TxAuth-But-For-Tiny-Things ;-)

Cheers.

Fabien

On Wed, Mar 11, 2020 at 7:53 PM Justin Richer <[e-mail]> wrote:

> Hi Fabian,
>
> Thanks for the note about the charter. Hopefully I can explain what we
> mean by the current scope language.
>
> The intent was to build a protocol that is bound to HTTP and not to other
> transport mechanisms. However, the design goal is to build it in such a way
> that when we use an HTTP feature, such as a header or verbs or URL
> parameters, we’re explicit about what we’re using and how. Therefore, when
> someone wants to map this concept and structure to another protocol stack,
> they’ll be able to say things like “I need the equivalent of an HTTP header
> for this part of the protocol” and use what best applies within their
> chosen space.
>
> What I explicitly wanted to avoid was this group defining something that
> was completely abstract with a nominal “binding” to HTTP as a transport
> mechanism. In my experience, this inevitably leads to an abstraction layer
> that doesn’t make sense in practice, and ultimately a confusing set of
> documents where people are trying to figure out which document has the
> details for what they care about. Especially since the first binding is
> often the only one that gets picked up and used by implementors.
> Abstracting things too early just leads to disaster, in other words.
>
> That’s why I think we’re better of doing something with an explicit
> connection to other layers, specifically including HTTP, JSON, TLS, and
> even JOSE the like. That way when someone wants to build TxAuth on top of
> CORE, CBOR, DTLS, and COSE, they can do the translations from the original
> protocol in ways that make the most sense. For instance, such an
> implementation would likely want to use OSCORE/COSE for a key presentation
> and proofing mechanism. This protocol set allows you to encapsulate the
> messages in ways that even HTTP signatures don’t. But if we build the
> entire protocol around, for instance, JOSE objects within an HTTP message,
> then we lose the ability to make that kind of translation.
>
> I also think it’s probably too much for this group to start with IoT and
> alternate transports on its plate, especially because, as you note, there
> are many of them and they’re often pretty different from each other. But we
> can have these in mind as we are developing TxAuth, and especially if a
> specifically interested party such as your own group is tracking TxAuth and
> making those translations in real time as we move the base protocol.
>
> Maybe the constrained version of TxAuth will find a home in this WG, maybe
> it’ll find a home elsewhere like ACE, or maybe we’ll have
> TxAuth-But-For-Tiny-Things as a WG in the future. In all of these cases,
> the people working on this are likely going to overlap at least a little
> with the people working on TxAuth itself.
>
> I hope this clears up the intent behind the wording of the charter! If
> there’s a better way to state that, please suggest some succinct text.
> Thanks!
>
>  — Justin
>
> On Mar 11, 2020, at 5:49 AM, Fabien Imbault <[e-mail]>
> wrote:
>
> Hello,
>
> Thanks for the work being done. I'm new to IETF (but have worked in the
> past with other collaborative orgs) so please forgive any unusual habits if
> any, will try to catch up.
>
> > 1.  Do you support the charter text provided at the end of this email?
> Or do you have major objections, blocking concerns or feedback (if so
> please elaborate)?
>
> Yes, with comments.
>
> I believe the last part of the charter : "will strive to enable simple mapping to other protocols such as COAP when doing so does not conflict with the primary focus" should be modified, to acknowledge what is really in the scope and what is not. As it is written, I actually don't know very well.
>
> Certainly the main goal is HTTP support and that is already a large challenge which needs to be handled with priority.
>
> However we need to acknowledge contrained devices are now very common, people want to manage them properly but usually those devices don't speak well over HTTP. From the content available on oauth.xyz, I have the impression that the use case is in the scope. That makes also be a great differentiation compared to OAuth2, and one doesn't have to fight so much with change management as the field is much newer, compared to webapps. In the IoT domain, that would be very useful because implementing delegation at scale is a real/unsolved issue.
>
> But as the charter is currently written, it is unclear what "simple mapping" really means and whether that could work out in practice as an after thought. I also have the feeling that saying the mapping to other protocols should not conflict with the primary focus doesn't make it so much clearer on what is exactly expected.
>
> Supporting a variety of IoT protocols is obviously out of question. So I suggest we get back to the requirements, and would propose the following: the protocol shall be usable by constrained devices, provided they can discuss over an IP network such as CoAP (see the work on OAuth2 ACE for instance), SCHC (which is also an upcoming IETF RFC) or other future protocols that would allow the interface to match with HTTP behaviour (through an adaptor). For those types of clients, the communication stack (supported and/or prefered) could be declared in a pre-register phase.
>
> What would still be out of scope is to design network protocol independance within TXAUTH. For instance, stateful data centric protocols such as MQTT would be out of scope.
>
> My team and myself are available to work on this (both on spec and opensource implementation prototype), and make constrained devices a first class citizen, if you agree that's indeed a common need. Of course, I do not intend this to be the priority, but more as a way to take feedback and make sure the protocol's design doesn't forbid such demands, likely to become mainstream.
>
> Please let me know what you think.
>
>
> > 2.  Are you willing to author or participate in the development of the
> drafts of this WG?
>
> Yes.
>
> > 3.  Are you willing to help review the drafts of this WG?
>
> Yes.
>
> > 4.  Are you interested in implementing drafts of this WG?
>
> Yes, rust implementation (and webassembly bindings).
>
> Best regards,
>
> Fabien
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>