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

[Fabien Imbault <[e-mail]>]

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