Re: [Txauth] Decoupling consent and authorization

[Fabien Imbault <[e-mail]>]

Thanks Justin. I have written a use case for that.

Cheers

Fabien

On Mon, Aug 3, 2020 at 8:27 PM Justin Richer <[e-mail]> wrote:

> Thank you for the clarifications! Yes, I agree that with these
> simplifications the protocol collapses quite nicely like this. I wonder if
> this could be an area where GNAP could provide support for those that need
> the extra connections but stay out of the way of those that don’t — like
> how token introspection allows a runtime query of a token’s status and
> capabilities, but nobody’s suggesting it be mandated for all systems (for
> what I hope are obvious reasons!). Then perhaps just like introspection
> this could be an “internal protocol” that interested AS’s would use, but
> whether or not it got used wouldn’t affect the outside of the protocol.
> This kind of functional layering is a really good design goal.
>
> Another thing, this makes me wonder if we should in fact split up the role
> of what’s classically been the AS into two functional roles. One part talks
> to the client, the other part interacts with the user (interaction
> server?). The connection between these components is what this “internal
> protocol” would define, though there would be other ways to handle it if
> you wanted to, just like with introspection.
>
> If you haven’t done so yet, I would recommend that you write up some pages
> in the Use Cases wiki describing the kinds of things you’re after:
>
> https://github.com/ietf-wg-gnap/general/wiki/Use-Cases
>
>  — Justin
>
> On Aug 3, 2020, at 12:22 PM, Fabien Imbault <[e-mail]>
> wrote:
>
> Hi Justin,
>
> Thanks for your feedback. The point is indeed to evaluate whether this
> opens up new capabilities.
>
> A preliminary response:
>
> 1) yes, we would have to sign the request, by any mean supported by GNAP.
> 2) right now it's pretty much hardcoded, which would be fine in some
> cases; but more generally the way that requirement is gathered into GNAP
> still needs to be worked out: probably the Client needs to do a first call
> to the RS before. This is important to know if we want to keep it as an
> implementation detail, that the Client may not even care about. Could be
> part of the request (the simplest, but is it fine with privacy requirement
> if we need to route through the AS?) or we could have continuation Tx
> specific to the consent component.
> 3) we have a very basic example (global yes/no) in which we didn't have to
> care (the flow either continues or stops), but indeed, we would need a
> second complete HTTP roundtrip (in a simple implementation) or allow more
> advanced communication patterns to reduce roundtrips (we have more
> flexibility since the Client in not in the loop here). There's currently a
> lot of work on 0-RTT in workgroups such as DIDComm and QUIC that we could
> leverage for some high perf scenarios.
>
> I'll work on a more advanced proposal for these, still a lot of work in
> order to keep things simple and stupid ;-)
>
> Cheers
>
> Fabien
>
> On Mon, Aug 3, 2020 at 5:33 PM Justin Richer <[e-mail]> wrote:
>
>> Fabien,
>>
>> Thanks for writing this up, this is interesting work! So if I’m reading
>> this correctly, the “interact_ref” portion is now also used to connect the
>> consent component with the AS, right? I like how it folds in the
>> verification of components with a really simple calculation, and that
>> allows the steps to be chained together. I really like that the extra steps
>> don’t affect what the client needs to know or what it has to do, so a
>> server could deploy with or without this and not change client behavior.
>>
>> I have a couple questions about how you think this might play out in a
>> deployment:
>>
>> 1) Do you think the interact server would sign its request to the AS in
>> 7? Since it’s a direct HTTP POST this should be able to use any of the
>> signing/proof mechanisms that the rest of GNAP would use.
>> 2) How does the interaction server get information about the consent
>> being gathered, in order to display the appropriate UI to the user? This
>> seems like it could be part of the exchange in 7/8 but I’m not sure what
>> the details would look like, any thoughts there?
>> 3) How does the interaction server communicate the results of the consent
>> back to the AS? It seems like that would require a second round trip.
>>
>>
>> I’m particularly interested in this idea because it could allow
>> standardization of something that OAuth is really bad at: interaction
>> through components that are not accessed via web browser. Think of it like
>> this: you’ve got an AS that handles the tokens and managing state and all
>> that, but you’ve got an on-device app to handle the actual consent and user
>> interaction portions. Previously, I’d hand-waved that they’d talk to each
>> other somehow, but this approach could give us a way for that on-device app
>> to talk back to the AS, get the information it needs to draw a UI, and
>> continue the request without it needing to have a full view of everything
>> back at the server.
>>
>>  — Justin
>>
>> On Aug 3, 2020, at 7:15 AM, Fabien Imbault <[e-mail]>
>> wrote:
>>
>> Hello,
>>
>> This is a new thread.
>>
>> I have just published a proof of concept that separates the interaction
>> from the rest of the AS. The goal is to open up the door to a privacy
>> preserving flow such as the one suggested by Denis (the interaction may be
>> handled by a Client endpoint, if it wishes), as well as to optimize the
>> implementation to each concern (UX for consent vs authorization flows).
>>
>> Note that it ends up being an implementation detail as far as the Client
>> is concerned, as the core request/response format wasn't changed from the
>> original XYZ protocol.
>>
>> The code and documentation is available publicly at:
>> https://github.com/acertio/mvp_gnap_interact
>>
>> The flow is sketched and explained at
>> https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#process
>>
>> Let me know what you think.
>>
>> Cheers
>>
>> Fabien
>>
>> --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>>
>