Re: [Txauth] Call for WG name preferences

[Dick Hardt <[e-mail]>]

Thanks for the response Justin, but you did not answer my questions. My
question was why was "intent lodging" selected.

I am also not sure what "the intent lodging pattern" is.

Additionally, you say, "we’ve got an opportunity to do a whole lot more
than that and to really question the model and capabilities that a
delegation protocol can bring."

This sounds nice, but is not specific. Would you share more on what you
think we should question, and what the opportunities are? Assume most of us
have not read oauth.xyz or seen your talks on the topic.
[image: image.gif]


On Fri, Jun 5, 2020 at 12:48 PM Justin Richer <[e-mail]> wrote:

> PAR aligns itself with OAuth 2 terminology, as it should given it’s an
> OAuth 2 extension. And I’ll point out that it isn’t a “request” but an
> “authorization request” which is a specific item. The “request” variable
> name is actually from OIDC, where it is used as a means to protect
> information while it is in the front channel and not in an intent lodging
> pattern.
>
> For people who want just the intent lodging pattern in an OAuth 2
> compatible way, PAR is absolutely the way to go and I encourage people to
> do just that. If you do that, you can re-use client IDs and scopes and
> client secrets and everything else directly. So if, for example, you’re
> doing OIDC today and you want to get the benefits of the intent lodging
> pattern while changing the minimum amount of code, then you should be using
> PAR. It even allows you to package the entire incoming request to the PAR
> endpoint as a JWT, since it can use OIDC’s request objects as part of the
> incoming request.
>
> But it’s not ideal, because it’s grafted on to a system that wasn’t meant
> to have it. Having implemented it on several platforms now I can say that
> it’s a little odd to get right, as is the case with most OAuth 2 extensions
> that have to deal with its quirks and baggage. I bring this up because our
> proposed charter and working group goal aren't just to implement PAR with
> slightly prettier syntax; instead, we’ve got an opportunity to do a whole
> lot more than that and to really question the model and capabilities that a
> delegation protocol can bring. That’s why we aren’t just an offshoot of the
> OAuth WG in the first place. And because of that, this working group is
> going to need to be able to direct implementors and conversations in the
> appropriate direction (which is also part of our charter), and things like
> PAR key to that conversation in helping people find the right solution that
> fits their needs. Not everyone’s going to want or need what we’re building
> here, and we need to be OK with that.
>
> In my time working with XYZ over the last year and a half or so, I’ve had
> a number of people approach me to see if it’s a good fit for what they’re
> doing. In some cases, it really is, for a lot of the reasons that we
> outline as needs to address within the charter. In a bunch of cases,
> though, I’ve pointed people at PAR, RAR, DPoP, and related work because it
> makes more sense for many people to be more tightly aligned with the
> existing OAuth 2 ecosystem. But if you aren’t already tied to OAuth 2 or
> OIDC, it might not be worth the trouble. As a consultant I’m used to doing
> that kind of redirecting, but the unique niche this working group will
> occupy alongside OAuth means we’re going to need to do it as a community as
> well. Otherwise, we run the risk of new work being unnecessarily fettered
> to old ways, or of people not availing themselves of legacy solutions that
> would work better for them just because they think this work is the new
> shiny that they’re supposed to use instead. This is why the proposed
> charter says we aren’t building things that are necessarily compatible with
> OAuth 2 — they can and should be influenced by the ecosystem of OAuth 2,
> but it’s also our job to help the new protocol evolve beyond that.
>
>  — Justin
>
> On Jun 5, 2020, at 1:25 PM, Dick Hardt <[e-mail]> wrote:
>
> Thanks for posting Justin, speaking for myself, I
> appreciate the background as I had not seen the term "intent" be used.
>
> Can you share any history why "lodging intent" was the term selected vs
> other choices? Why not "request"? Overused?
>
> To me, an intent is an action ie. the client saying "I am going to do X",
> whereas a request is asking for something, the client saying "I would like
> X"
>
> Or is the idea the client saying "I intend to request X"?
>
> FWIW: I don't see the term "intent" used in PAR. It is a "request".
>
> On Fri, Jun 5, 2020 at 7:59 AM Justin Richer <[e-mail]> wrote:
>
>> Since there seems to be some confusion by a few people about the term
>> “Intent” and its inclusion here, I wanted to clarify that for people. There
>> is a protocol feature is variously known as “intent registration” or
>> “lodging intent”, where the party starting the process (the client) makes a
>> statement about what it wants to do and is then given the tools to complete
>> the next steps to do that. It’s a key feature of the pattern we’re looking
>> to codify in this group’s work.
>>
>> The FAPI working group in the OIDF has done a lot of work around it, and
>> you see this style in a bunch of different financial APIs dating back
>> decades:
>>
>>
>> https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md
>>
>> https://bitbucket.org/openid/fapi/issues/142/standardising-lodging-intent
>>
>>
>> Torsten Lodderstedt has a great blog post that touches on it as well:
>>
>>
>> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>>
>> And it’s the basis behind OAuth 2.0’s Pushed Authorization Request (PAR)
>> extension that’s happening now:
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-par
>>
>>
>> https://medium.com/oauth-2/pushed-authorization-requests-draft-adopted-by-oauth-working-group-a1060007150f
>>
>>
>> To be clear, I’m not saying this is sufficient for it driving the name,
>> but I do think it’s important that people be familiar with this terminology
>> as its likely to come up again as the work progresses.
>>
>>  — Justin
>>
>> On Jun 4, 2020, at 7:25 PM, Mike Jones <
>> Michael.Jones=[e-mail]> wrote:
>>
>> *Prefer:*
>>     * GNAP    Grant Negotiation and Authorization Protocol – The focus on
>> grants is correct.  And it’s a snappy name.
>>     * GranPro    GRAnt Negotiation Protocol – The focus on grants is
>> correct.  Pronounceable.
>>     * NIRAD    Negotiation of Intent Registration and Authority
>> Delegation – Cool sci-fi sounding name.
>>     * PAuthZ    Protocol for Authorization – Accurate description.
>>     * RefAuthZ    Refactored Authorization Protocol – Accurate
>> description.
>>     * ReAuthZ    Reimagined Authorization Protocol – Accurate description.
>>     * WRAC (Web Resource Authorization Collaboration) - Pronounced like
>> RACK – Cool name, with history going back to OAuth WRAP.
>>     * XAuthZ    eXtensible authoriZation protocol – Accurate description.
>>
>> *Wouldn't object to:*
>>     * AAuthZ    Alternative Authorization Protocol (AAuthZ)
>>     * AZARP    AuthoriZed Access to Resources Protocol
>>     * AZARAP    AuthoriZation And Resource Access Protocol
>>     * BeBAuthZ    Back-end Based Authorization Protocol
>>     * DAZARAP    Delegated AuthoriZation And Resource Access Protocol
>>     * TINOA   This Is Not OAuth
>>
>> *Object to:*
>>     * BYOAuthZ    Build-Your-Own Authorization Protocol – Too cheesy.
>>     * CPAAP    Comprehensive Privileged Authentication Authorization
>> Protocol – Too much like a medical device name.
>>     * DIYAuthZ    Do-It-Yourself Authorization Protocol – Too cute.
>>     * IDPAuthZ    Intent Driven Protocol for Authorization – IDP already
>> means something else.
>>     * TIAAP    Tokenized Identity and Access Protocol – I don’t know what
>> “tokenized” is referring to here.
>>     * TIDEAuth    Trust via Intent Driven Extension Auth – I don’t know
>> what “intent” is referring to here.
>>     * TIDYAuth    Trust via Intent Driven Yield Auth – I don’t know what
>> “intent” is referring to here.
>>     * TIEAuth    Trust via Intent Extension Auth – I don’t know what
>> “intent” is referring to here.
>>     * TXAuth    Testable eXtensible Authorization – I don’t know what
>> “testable” is referring to here.
>>     * TxAuth      Transmission of Authority – It’s delegation of
>> authority – not transfer of authority.
>>     * TXAuth      Truly eXtensible Authorization – Too cute.
>>
>>                                                        -- Mike
>>
>> --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>> --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> ᐧ
>
>
>