Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

That’s true when the front channel (redirects between parties) is used as the method for interaction, but the point I was making is that that method isn’t going to be the only way that interaction happens. I don’t think it’s helpful to conflate other interaction mechanisms that don’t use redirections with URIs and query parameters as “front channel” here. The security models and surrounding assumptions are very different. 

 — Justin

> On Aug 13, 2020, at 11:40 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
> 
> I've often thought of front channel as an interaction visible to the user, and back channel as being between two software systems, in this case, the client and GS.
> 
> Consent from the user is the front channel, independent of how the user gets to the GS, or if an app is part of the GS, or is the GS.
> ᐧ
> 
> On Thu, Aug 13, 2020 at 8:34 AM Fabien Imbault <fabien.imbault@gmail.com <mailto:fabien.imbault@gmail.com>> wrote:
> Indeed.
> 
> On Thu, Aug 13, 2020 at 5:33 PM Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
> A point I forgot to make below: the “front channel” isn’t going to exist for a lot of systems anymore, where interaction happens through an app or communication happens through some separate communication fabric. So there are cases, just like in OAuth 2, where there’s only a “back channel” and the other aspect of the AS never comes into play.
> 
>  — Justin
> 
>> On Aug 13, 2020, at 11:17 AM, Fabien Imbault <fabien.imbault@gmail.com <mailto:fabien.imbault@gmail.com>> wrote:
>> 
>> Without surprise, +1 to differentiate between the back-channel and the front-channel.
>> 
>> On Thu, Aug 13, 2020 at 5:15 PM Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>> Denis, I want to focus on one point here:
>> 
>>> In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.
>>> 
>>> Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS, 
>>> instead of the AS. This means that we should define a "consent" endpoint at the RS.
>> 
>> One of my goals with XYZ’s design was to be able to separate the interaction with the user from the web-based flows for the delegation protocol, and that aspect is enshrined in the GNAP charter as well.
>> 
>> It points to the reality that there are two different aspects of the traditional AS that we might need to talk about separately now. One deals with delegation, issuing tokens, returning data directly to the client (not through a separate API, since that’s the RS), and other back-channel stuff. The other aspect deals with interacting with the user and/or resource owner. 
>> 
>> We already saw bits of this in OAuth 2: the AS is defined by the pair of the token endpoint and authorization endpoint, each filling the respective roles above. What if we formally separate these? Strawman names:
>> 
>> 
>> Delegation Server (DS) - handles the back-channel stuff
>> 
>> Interaction Server (IS) - handles the front-channel stuff
>> 
>> 
>>  — Justin
>> 
>> -- 
>> TXAuth mailing list
>> TXAuth@ietf.org <mailto:TXAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 