Subject: Re: [Txauth] alignment on Justin's use of "transactional" adjective

From: Mike Jones <[email-masked]>
Date: Wed, 22 Apr 2020 01:19:58 +0000

-1 to “transactional”

I and others have proposed many more accurate adjectives including:

  *   Disaggregated
  *   Componentized
  *   Build-Your-Own
  *   Do-It-Yourself
  *   Refactored
  *   Dismembered
  *   Yet Another
  *   Alternative
  *   Reimagined
  *   Back-end Based

Let’s use one of them or find another one.

FYI, my current favorite name is YAAP – Yet Another Authorization Protocol.

                                                          -- Mike

From: Txauth <[email-masked]> On Behalf Of Dick Hardt
Sent: Tuesday, April 21, 2020 6:13 PM
To: [email-masked]
Subject: [Txauth] alignment on Justin's use of "transactional" adjective

With the recent threads on the name, I'm going to make a push to get consensus. While there are many of you that don't care, there are also many that do care (myself included)

There have been a number of people (including myself) concerned with the protocol being called a transaction, there may be others (besides Justin) that are aligned with Justin's definition that have not felt a need to say anything.

So let's get some feedback:

Transactional Authorization. It’s an authorization that has aspects and components and artifacts of a transaction.

If you are aligned using "transactional", please respond with a +1

If you are not aligned, please respond with a -1

If you don't care, don't bother responding. :)

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 22 Apr 2020 14:58:03 +0300

I am mostly in the Don’t Care camp on this. However:

“trade” is the name of a concluded working group, so it’s not an option.
I personally don’t like the “yet another” prefix. To me it is belittling, without adding any useful semantics. It may have been fun when YACC came about (1970 or so), but IMHO not since.

Thanks,

                Yaron

From: Txauth <[email-masked]> on behalf of Mike Jones <Michael.Jones=[email-masked]>
Date: Wednesday, April 22, 2020 at 04:20
To: Dick Hardt <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] alignment on Justin's use of "transactional" adjective

-1 to “transactional”

Disaggregated
Componentized
Build-Your-Own
Do-It-Yourself
Refactored
Dismembered
Yet Another
Alternative
Reimagined
Back-end Based

                                                          -- Mike

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

---

From: George Fletcher <[email-masked]>
Date: Wed, 22 Apr 2020 08:18:45 -0400

Generally I'm -1 to "transactional" (though I fully admit I'm biased 
because I have an idea I'm calling "Transaction Tokens" [dealing with 
authorizing a single transaction within a micro-services like 
architecture] :)

I'm definitely against YAAP; largely for the reasons Yaron mentions.

I'm a bit sad that TRADE is not a option because that was my preferred 
option.

For XYZ/XAuth the authorization has a bit of shared component. It's kind 
of a negotiation between the client, the authorization server and the 
resource owner. This is in contrast to many centralized authorization 
models where authorization is granted based on the identity of the 
requestor.

I'm really bad at naming but I'll throw this out there "Client Initiated 
Authorization" :)

---

From: Mike Varley <[email-masked]>
Date: Wed, 22 Apr 2020 12:55:28 +0000

+1 to “transactional”
Although I’m not strongly tied to the adjective, I haven’t seen a suggestion that more accurately captures the intent of the protocol, which to my mind can be summarized as:
There is a pre-flight setup transaction required by clients to authorization servers before the OAuth request/response (transaction) process can begin to ensure that the following authorization (transaction) elements include but are not limited to:

  1.  The client is authorized to even attempt the end-user authentication/authorization.
  2.  The client and authorization server have a clear understanding each other’s user engagement capabilities and requirements.
Further, clients and authorization servers are not limited to the same static relationship for all authorization transactions.

Thanks,

MV

From: Txauth <[email-masked]> on behalf of George Fletcher <gffletch=[email-masked]>
Organization: AOL LLC
Date: Wednesday, April 22, 2020 at 8:19 AM
To: Yaron Sheffer <[email-masked]>, Mike Jones <Michael.Jones=[email-masked]>, Dick Hardt <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] alignment on Justin's use of "transactional" adjective

Generally I'm -1 to "transactional" (though I fully admit I'm biased because I have an idea I'm calling "Transaction Tokens" [dealing with authorizing a single transaction within a micro-services like architecture] :)

I'm a bit sad that TRADE is not a option because that was my preferred option.

For XYZ/XAuth the authorization has a bit of shared component. It's kind of a negotiation between the client, the authorization server and the resource owner. This is in contrast to many centralized authorization models where authorization is granted based on the identity of the requestor.

I'm really bad at naming but I'll throw this out there "Client Initiated Authorization" :)
On 4/22/20 7:58 AM, Yaron Sheffer wrote:

Thanks,

                Yaron

From: Txauth <[email-masked]><mailto:[email-masked]> on behalf of Mike Jones <Michael.Jones=[email-masked]><mailto:Michael.Jones=[email-masked]>

To: Dick Hardt <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

-1 to “transactional”

Disaggregated

Componentized

Build-Your-Own

Do-It-Yourself

Refactored

Dismembered

Yet Another

Alternative

Reimagined

Back-end Based

                                                          -- Mike

From: Txauth <[email-masked]><mailto:[email-masked]> On Behalf Of Dick Hardt

To: [email-masked]<mailto:[email-masked]>

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

This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.

---

From: "Hjelm, Bjorn" <[email-masked]>
Date: Wed, 22 Apr 2020 14:14:02 -0700

I'll echo George's comments and that, to me, TRADE was a more
representative naming convention to what I thought this effort was intended
to achieve.

BR,
Bjorn

On Wed, Apr 22, 2020 at 5:19 AM George Fletcher <gffletch=
[email-masked]> wrote:

> authorizing a single transaction within a micro-services like architecture]
> :)
>
> From: Txauth <[email-masked]> <[email-masked]> on behalf of Mike Jones <Michael.Jones=[email-masked]> <Michael.Jones=[email-masked]>
> To: Dick Hardt <[email-masked]> <[email-masked]>, "[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]>
> From: Txauth <[email-masked]> <[email-masked]> On Behalf Of Dick Hardt
> -- Txauth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/txauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_txauth&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=NMZJHCV8pjvGIH2fTx9z6l7g7-V-a2xW7ISf9uHdz0A&m=BbfoEaxqwjDSx3al9wGOfsV_OxqCWgg9d9O_Hzkfk50&s=benl0gCRrA1QlJya2-3opiXO7L6rdeu2racWz0rZtH4&e=>
>
>
>
> --
> Txauth mailing list
> [email-masked]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_txauth&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=NMZJHCV8pjvGIH2fTx9z6l7g7-V-a2xW7ISf9uHdz0A&m=BbfoEaxqwjDSx3al9wGOfsV_OxqCWgg9d9O_Hzkfk50&s=benl0gCRrA1QlJya2-3opiXO7L6rdeu2racWz0rZtH4&e=
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 22 Apr 2020 15:43:52 -0700

On Wed, Apr 22, 2020 at 5:55 AM Mike Varley <[email-masked]>
wrote:

> ... the intent of the protocol, which to my mind can be summarized as:
>
> There is a pre-flight setup transaction required by clients to
> authorization servers before the OAuth request/response (transaction)
> process can begin
>
<snip>

This is also what I think it the major change to the protocol.

/Dick

---

From: Justin Richer <[email-masked]>
Date: Wed, 22 Apr 2020 20:20:22 -0400

> On Apr 22, 2020, at 6:43 PM, Dick Hardt <[email-masked]> wrote:
> 
> On Wed, Apr 22, 2020 at 5:55 AM Mike Varley <[email-masked] <mailto:[email-masked]>> wrote:
> There is a pre-flight setup transaction required by clients to authorization servers before the OAuth request/response (transaction) process can begin
> 
> <snip>
> 

It’s one major change, but if that were all then we’d be fine with just developing PAR on top of OAuth 2.

Another major change is the interaction model moving away from assuming everyone’s in a browser. 

Another major change is moving away from the assumption that clients are web servers that have been pre-registered.

There are plenty more aspects, as have been enumerated in the proposed charter text that got general support.

 — Justin

---

From: Dick Hardt <[email-masked]>
Date: Thu, 23 Apr 2020 18:09:21 -0700

On Wed, Apr 22, 2020 at 5:20 PM Justin Richer <[email-masked]> wrote:

> Another major change is moving away from the assumption that clients are
> web servers that have been pre-registered.
>

These are changes in the parties, and were supported in OAuth 2.0. We are
thinking of them up front here and improving how they are supported.

The ACTUAL protocol change (how the parties talk to each other) is that the
client ALWAYS talks to the AS first.

Lots of other aspects are being improved based on what we know now.
ᐧ