Re: [Txauth] Decoupling consent and authorization

Here is an alternative to that consisting of two token "niblets",
essentially signed and encoded tokens that are designed to be embedded in
an az token. These can be viewed as lite-weight VCs.
https://wiki.idesg.org/wiki/index.php/Delegation

https://wiki.idesg.org/wiki/index.php/Delegation

and the consent to create binding which can be viewed as the user doing
dynamic registration.
https://wiki.idesg.org/wiki/index.php/Consent_to_Create_Binding

These are IMHO necessary to do distributed identity.

thx ..Tom (mobile)

On Mon, Aug 3, 2020, 8:34 AM Justin Richer <jricher@mit.edu> 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 <fabien.imbault@gmail.com>
> 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
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>