Re: [Txauth] TLS Dependency

[Wayne Chang <[e-mail]>]

Shifting to a new thread based on the interesting point Tom made about removing TLS requirements. Justin, I did see that you were careful to specify "TLS or equivalent" in your drafts, and Dick commented "[Editor: too aggressive to mandate HTTP/2 and TLS 1.3?]" in his. Maybe this is a good opportunity to explore the "or equivalent" part.

Some IoT environments do not and will not support HTTP + SSL/TLS, but could benefit from this grant framework. Instead, they may use application protocols like MQTT and more recently in conjunction with single-packet authorization (SPA). https://ieeexplore.ieee.org/document/8930455

>From the DID ecosystem, I can imagine some future interoperability between DIDComm and GNAP. It is not clear that TLS will be used for all DID-to-DID communications, which aim to be transport agnostic. See discussion here: https://github.com/decentralized-identity/didcomm-messaging/issues/38

What other potential non-TLS use cases are worth mentioning?

On Wed, Jul 8, 2020, at 1:10 PM, Tom Jones wrote:
> a somewhat milder response might be.
> It seems that justin's proposal is not, in fact, a grant negotiation, but a generalized token format.
> So - what could that mean here?
> I have a problem with the whack-a-mole approach of OAuth, with RAR JAR ad infinitum.
> That is a never-ending stream of hacks.
> if Justin's proposal is to be considered seriously, it must be at some higher level that GNAP..
> I suggest that the current approach of xauth txauth authxyz is not really headed to a convergence.
> Perhaps we need to start with an abstract set of goals and data flows. One that includes the user/RO.
> I do have one for healthcare - but i am short of time right now to generalize it.
> One item I would like to see resolved early is to remove the dependency on transport layer security. One that includes the handling of key roll-over.
> In Kantara we focused first on the legal responsibilities of the token maker. That problem seems to have consumed FAPI, altho they have multiple names for it.
> In the real world we have legal entities (natural and unnatural) and legal names (brands) as well as pseudonyms. OAuth just had endpoints with SSL keys and certs. How about we start there?
> Peace ..tom