Re: [GNAP] GNAP Architecture and the role of the AS

[Adrian Gropper <[e-mail]>]

I share the goal of finding the appropriate extension points but I'm having
a hard time following the conversation because we're not talking about the
specific use case.

Let me try and recap:
- The doctor is live and using a client application to place a request to
an AS that pertains to a particular RO as the subject.
- The RO has delegated authorization to an on-line agent and the RO
themselves may be offline.
- Any of the various actors in the GNAP protocol may raise warnings or
exceptions and could try to reach the RO if provided with appropriate
hints. The actual mechanisms for contacting the RO are likely out of scope
for GNAP but we do need to consider the extension points and hints for some
or all actors we do identify in the GNAP spec.
- Given the above, Justin is proposing that the AS and the agent are
separate actors, both online, and need to interact in order to turn the
doctor's request into an authorization token.
- This interaction between the AS and the agent is clearly at the heart of
GNAP and how we explain GNAP to others.
- If the RO's policies are in one actor (the agent) and the request is
presented to another actor (the AS) then GNAP becomes a protocol for how an
agent interacts with an AS.
- The capability to be turned into an authorization token originates with
the RS-RO relationship. It could have been given to the RO, the agent, or
the AS initially. Some of these might be out of scope for GNAP and others
need to be specified.
- The capability to issue an authorization needs is the third essential
component of GNAP along with policies (at the agent) and a request receipt
endpoint (of the AS).
- The RO has a privacy interest in getting the request in a way that the AS
does not benefit from.

GNAP must not force the agent to share request information with anyone that
is not a principal to the transaction. Those principals are the RO, their
agent, and the RS.

Adrian

On Tue, Mar 16, 2021 at 11:00 AM Fabien Imbault <[e-mail]>
wrote:

> Same, thanks for the clarification.
>
> On Tue, Mar 16, 2021 at 3:11 PM Justin Richer <[e-mail]> wrote:
>
>> Responses inline..
>>
>> On Mar 16, 2021, at 9:19 AM, Fabien Imbault <[e-mail]>
>> wrote:
>>
>> Hi Justin,
>>
>> My comments in red [FIM].
>>
>> Cheers
>> Fabien
>>
>> On Tue, Mar 16, 2021 at 1:14 PM Justin Richer <[e-mail]> wrote:
>>
>>> On Mar 15, 2021, at 10:16 PM, Adrian Gropper <[e-mail]>
>>> wrote:
>>>
>>> Hi Justin,
>>>
>>> I have exactly the same two questions as Fabien and also, I worry about
>>> the handwaving in the answer to 7.
>>>
>>>
>>> The handwaving is actually important. I don’t think that’s something
>>> that GNAP will solve in a universal way. We can have hooks in the core
>>> protocol that say “and now go do This Other Thing to talk to an agent”, but
>>> I don’t think we’re really the best ones to decide what that is or what it
>>> looks like for everyone.
>>>
>>> This could be DIDComm, it could be CHAPI, it could be some proprietary
>>> app connection with push notifications, it could be writing/reading from a
>>> shared encryption storage fabric — all that’s important here is that GNAP
>>> has a place in the protocol where these various things can fit.
>>>
>>> OAuth chose HTTP Redirects as The Way to get users involved in the
>>> process, but GNAP is taking a very different stance in trying to get away
>>> from that limiting assumption. I don’t think it would serve us to just make
>>> a different limiting assumption about how users (and their decisions) get
>>> involved.
>>>
>>
>> [FIM] We shouldn't be looking for an universal carrier, I agree, but
>> people will need practical ways to implement that. I think there's a fine
>> line between avoiding limiting assumptions and GNAP remaining too
>> conceptual. At least we should know where to put the extension points.
>>
>>
>> I agree that we need to have the extension points in the right place. In
>> order to do that, we need to know what we’re extending, which was the
>> impetus for starting this conversation. It’s debatable how much further we
>> want to go beyond that in GNAP itself, especially since there are a lot of
>> other protocols out there designed to fit this niche well (see examples
>> above).
>>
>> One step we definitely can help with is providing a cohesive model for
>> describing both people and access rights, and being clear about the overall
>> process.
>>
>
> [FIM2] clearer to me, thanks.
>
>>
>>> To answer the questions;
>>>
>>> - we're covering the use case "get my medical data", how does that
>>>>> change if that's someone else's data?
>>>>>
>>>>
>>> It’s the same process as the second flow. The RO is the patient or
>>> doctor or someone who can approve things. The AS doesn’t get everything
>>> that it needs to from the agent introduced by the client, so it needs to
>>> access another agent.
>>>
>>
>>> - what happens if the agent can't guarantee availability?
>>>>>
>>>>
>>> Then the AS doesn’t get what it needs in order to fulfill the request
>>> and it denies the request. Whether that’s a timeout or some other error,
>>> and whether that comes back to the client with a “try again” or with a
>>> “tough luck, go away”, I think that’s all up for debate, and parts of that
>>> we’ll need answers for. But ultimately, it’s the same kind of thing that
>>> happens in OAuth if the user doesn’t consent, or the user can’t log in, or
>>> the “wrong” user logs in for what’s being asked for — the AS isn’t
>>> satisfied with the approval so the delegation request fails.
>>>
>>
>> [FIM]  seems realistic when user = RO, the end-user can make itself
>> available if the service is really important to him. "Tough luck" at first
>> failure is fine then.
>> But I believe that becomes impractical when a remote RO is involved (at
>> least if it's supposed to be a human: if we don't deal with unavailability,
>> async sequence 1.4.3 should be removed).
>>
>>
>> Then, what is the AS to do if it tries the methods necessary to reach the
>> RO, but those methods fail? Or if there are multiple RO’s who could approve
>> and multiple come back?
>>
> [FIM2] yes, that's some of the cases (and open questions) I put forward in
> the presentation, trying to identify what would have to be dealt with.
> It would be fine to decide all interactions need to be synchronous
> requests/responses in the core.
>
>>
>> I agree that these are situations the AS is going to have to deal with,
>> but I also believe that the details of what gets us into these situations
>> is outside of GNAP itself. Perhaps think of it this way:
>>
>>  - The AS needs to gather authorization and consent.
>>  - The client can direct interaction with the end user.
>>  - The end user might be able to provide that authorization and consent.
>>  - The client doesn’t know if the end user is the RO, but it can provide
>> the AS with hints as to who the end user is and means to interact with them
>> for the AS.
>>  - The AS knows who the RO is and might have ways to interact with them
>> (and their decisions) outside of the interface with the client.
>>
>> So in other words, the consent-gathering process that the AS goes through
>> can be both client-mediated and non-client-mediated. The client-mediated
>> portions are very much in scope of GNAP and they fall into the space of
>> user == RO very easily. The non-client-mediated interactions are outside
>> the scope of GNAP — or at least outside the core protocol, since the core
>> protocol is all about the client instance getting a token (and/or subject
>> info).
>>
> [FIM2] that could be a viable way to refine the scope of the core. As long
> as it's clear what we do, it's fine to me.
>
>>
>> I think we can expand the discussion in the draft of how the AS goes
>> through this consent gathering process but shouldn’t try to define one
>> specific way of it happening. That way we can define good behavior around
>> asynchronous methods, timeouts, and multi-user protocols, but without
>> having to define, say, a wire-based policy language to carry those
>> decisions. It’s definitely a fine line!
>>
> [FIM2] yes, for sure DIDComm was in my view just one example of a possible
> extended interact method (among many possible already today and more in the
> future).
> In practice, none of those non-client-mediated interactions need to be in
> the core. However, they would probably require that GNAP defines how one
> should react to such async or message based patterns, above the underlying
> protocol foundation, to provide "elegant, synchronous request-response
> interactions." (as said in 1.3.1 of DIDComm). Defining good async behaviour
> without minimal syntax is possible with coloring schemes, but they have
> their drawbacks too (forces you to always think in colors, even for basic
> sync cases, and so I'm not convinced that would be a win).
>
>>
>> Your flow for 8 doesn't make sense to me because I assume the client is
>>> on the RO's mobile device and unavailable for most interactions. The whole
>>> point of having the Agent is to keep the RO Client out of the picture when
>>> the requesting party shows up with their Client.
>>>
>>>
>>> The RO doesn’t have a client in any of the flows below. The RO might
>>> have an agent, they might have an app that notifies them to go log into a
>>> webpage asynchronously, they might get an email with a link to click back
>>> at the AS. None of that is facilitated through the RO’s client because the
>>> RO doesn’t have a “client” in this model. The client is by definition the
>>> software in front of the “user”, the requesting party.
>>>
>> [FIM] yes indeed
>>
>>>
>>> And it’s important in the design that the client doesn’t need to know
>>> about any of that. It can identify the resource, possibly identify the RO,
>>> and it can tell the AS “this is how I can talk to the person sitting in
>>> front of me right now” — for whatever definition of “talk to” makes sense
>>> for the client app. What it can’t reliably do is say “this is how I can get
>>> in touch with an RO that I’m not talking to”, and certainly not communicate
>>> with another client, another AS, or other part of the GNAP protocol.
>>>
>>
>> [FIM] Not entirely clear where we draw the line. I imagine "person
>> sitting in front of me right now" is not to be taken literally? (could be
>> my doctor, even if he's not in the same room).
>> Clearly there's no way a client can ever guarantee a reliable
>> communication with something else, I agree. At the very best it's a hint
>> (and possibly a bad one).
>>
>>
>> If the doctor isn’t using the client application, then the doctor’s not
>> the “user” in protocol terms. If the AS has some other way to get the
>> doctor involved, it should be able to do that, but the client can’t really
>> do anything about it.
>>
>>  - Justin
>>
>>
>>>  - Justin
>>>
>>>
>>> Adrian
>>>
>>> On Mon, Mar 15, 2021 at 10:12 PM Adrian Gropper <[e-mail]>
>>> wrote:
>>>
>>>> Hi Justin,
>>>>
>>>> I have exactly the same two questions as Fabien and also, I
>>>>
>>>> On Mon, Mar 15, 2021 at 9:45 PM Fabien Imbault <
>>>> [e-mail]> wrote:
>>>>
>>>>> Hi Justin
>>>>>
>>>>> A few questions :
>>>>> - we're covering the use case "get my medical data", how does that
>>>>> change if that's someone else's data?
>>>>> - what happens if the agent can't guarantee availability?
>>>>>
>>>>> Fabien
>>>>>
>>>>>
>>>>> Le lun. 15 mars 2021 à 20:42, Justin Richer <[e-mail]> a
>>>>> écrit :
>>>>>
>>>>>> Hi Adrian, thanks so much for writing up this use case. I’ve included
>>>>>> some thoughts below into how different aspects of GNAP might map to these
>>>>>> requirements. I don’t think mapping any human system to any technology is
>>>>>> clean and dry, but for what it’s worth I do see a lot of alignment.
>>>>>>
>>>>>> On Mar 12, 2021, at 4:34 PM, Adrian Gropper <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>> Let’s try to map a real-world use-case into the names and roles we
>>>>>> are discussing. The use-case is documented as the API Task Force
>>>>>> Recommendations (2016)
>>>>>> https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-APITFRecommendations.pdf
>>>>>> and I’ve copied below the most relevant section. Bold highlight is
>>>>>> in the original. I’ve added bold italic because it may be important
>>>>>> to our discussion.
>>>>>>
>>>>>> <quote>
>>>>>>
>>>>>>    -
>>>>>>
>>>>>>    ONC should clarify that while API Providers may impose security
>>>>>>    related restrictions on app access (e.g. rate limiting, encryption, and
>>>>>>    expiration of access tokens), it is inappropriate for API providers to set
>>>>>>    limitations on what a patient authorized app can do with data downstream.
>>>>>>    - Given the nature of patient access rights, the provider is not
>>>>>>       in a legal position to prevent the registration of apps that would
>>>>>>       aggregate or share data, for example (though the provider might certainly
>>>>>>       decide to warn the patient, or endeavor to educate and explain these issue
>>>>>>       to the patient, as part of the provider hosted app approval workflow).
>>>>>>       - ONC should clarify that API providers are not obligated to
>>>>>>    protect patients by identifying "suspicious" apps. API providers may
>>>>>>    suspend API access to an app that has breached the API provider's
>>>>>>    terms of service , or appears to have been compromised, or if the app poses
>>>>>>    a threat to the provider's own system. However, patients must be
>>>>>>    able to override this suspension (except in the case where an app
>>>>>>    poses threat to the provider's own system or violates allowable terms of
>>>>>>    service).
>>>>>>
>>>>>>
>>>>>> </quote>
>>>>>>
>>>>>> The key requirements from a patient rights and privacy perspective
>>>>>> are:
>>>>>>
>>>>>>
>>>>>>    1. To delegate a scope-limited access capability to anyone
>>>>>>    anywhere without having to explain or justify that to the API Provider.
>>>>>>
>>>>>>
>>>>>> This will always be susceptible to the level of granularity that the
>>>>>> API Provider allows the API to be accessed in.
>>>>>>
>>>>>> Standard APIs (which would result in standard “type” values in the
>>>>>> “access” request array) can help with this by defining sufficient levels of
>>>>>> detail. But ultimately, the user could never ask for a scope that the API
>>>>>> Provider isn’t willing to express.
>>>>>>
>>>>>>
>>>>>>    1. To allow the patient to automate the issue of a scope-limited
>>>>>>    access capability by delegating the authority to process API access
>>>>>>    requests to some agent. The API Provider has no say in who or where this
>>>>>>    agent is.
>>>>>>
>>>>>>
>>>>>> This is where I think this discussion really should go. On the
>>>>>> surface, this seems to lead to the “bring your own AS” model. I am
>>>>>> contending that it’s more powerful to have an AS (still under the API
>>>>>> Provider’s control) that allows the user to provide additional inputs
>>>>>> during the protocol process. As an industry, we can standardize and
>>>>>> innovate a lot of those inputs, but ultimately GNAP should be able to just
>>>>>> connect those endpoints to each other (in my opinion). One of the common
>>>>>> inputs is going to remain “get someone to log in at this webpage at the AS
>>>>>> and click a button”, but I’m convinced there will be others.
>>>>>>
>>>>>>
>>>>>>    1. The automation of the agent is based on policies provided by
>>>>>>    the patient. The agent is able to process access requests from anyone and
>>>>>>    is responsible only to the patient. The agent responds to successful
>>>>>>    requests by issuing a filtered capability to the requesting party.
>>>>>>
>>>>>>
>>>>>> In this case, shouldn’t it be that the agent is separated from the
>>>>>> AS? Since the patient is going to have data protected by different API
>>>>>> Provders, to me it stands to reason that they’d want the same agent acting
>>>>>> for them on different systems. Each of those systems would still have its
>>>>>> own AS, but the AS would be facilitated by the user’s input.
>>>>>>
>>>>>> Now this is NOT saying that the user would have their own AS to
>>>>>> delegate something to the downstream AS. Or even saying that the user would
>>>>>> have some kind of XACML policy server. I’m not sure exactly how the bits on
>>>>>> the wire would work but a strawman would look something like:
>>>>>>
>>>>>>
>>>>>> [image: https://www.websequencediagrams.com/?png=msc978356221]
>>>>>>
>>>>>> User -> Client: go access my medical data
>>>>>> Client -> RS: hey I want to access this medical data
>>>>>> RS -> Client: sure go talk to this AS
>>>>>> Client -> Agent: I need to make a request for data, how can I get the
>>>>>> AS in touch with you?
>>>>>> Agent -> Client: tell them to use [some kind of magic]
>>>>>> Client -> AS: hey I want to access this medical data; I can get the
>>>>>> user to interact with you or I can put you in touch with their policy agent
>>>>>> AS -> Client: OK I’ll talk to the policy agent
>>>>>> AS -> Agent: I have a request for data, I need you to prove that you
>>>>>> have the right to release this data
>>>>>> Agent -> User: It looks like Client is asking for stuff at RS through
>>>>>> AS, that cool?
>>>>>> Agent -> AS: OK, here you go [more magic]
>>>>>> AS -> Client: ok, here’s an access token that’s good for accessing
>>>>>> that AS
>>>>>> Client -> RS: hey, I want to access this medical data and here’s an
>>>>>> access token for it
>>>>>>
>>>>>>
>>>>>>
>>>>>>    1. To ensure that the requesting party can delegate the
>>>>>>    capability using an institutional workflow system that they trust and the
>>>>>>    patient doesn’t know or care about. In many cases, the workflow system will
>>>>>>    pass the capability to some other person, who we might call the end user.
>>>>>>    In other cases, the requesting party may forward the capability directly to
>>>>>>    another person using, for example, an email. Either way, the client app
>>>>>>    used by the end-user to access the API is of no concern to the patient or
>>>>>>    to the patient’s agent.
>>>>>>
>>>>>>
>>>>>> To facilitate this, the “agent” above can be augmented with other
>>>>>> capabilities based on what’s being asked for. Adding a line to the flow
>>>>>> above:
>>>>>>
>>>>>> User -> Client: go access my medical data
>>>>>> Client -> RS: hey I want to access this medical data
>>>>>> RS -> Client: sure go talk to this AS
>>>>>> Client -> Agent: I need to make a request for data, how can I get the
>>>>>> AS in touch with you?
>>>>>> Agent -> Client: tell them to use [some kind of magic]
>>>>>> Client -> AS: hey I want to access this medical data; I can get the
>>>>>> user to interact with you or I can put you in touch with their policy agent
>>>>>> AS -> Client: OK I’ll talk to the policy agent
>>>>>> AS -> Agent: I have a request for data, I need you to prove that you
>>>>>> have the right to release this data
>>>>>> Agent -> User: It looks like Client is asking for stuff at RS through
>>>>>> AS, that cool?
>>>>>> Agent -> AS: OK, here you go [more magic]
>>>>>> *AS -> RO: It looks like someone's asking for an RS you have the
>>>>>> approval for, that cool?*
>>>>>> AS -> Client: ok, here’s an access token that’s good for accessing
>>>>>> that AS
>>>>>> Client -> RS: hey, I want to access this medical data and here’s an
>>>>>> access token for it
>>>>>>
>>>>>> In other words, when the AS gets the request, it can and should take
>>>>>> in inputs from multiple different dimensions in order to make the
>>>>>> authorization decision and encode that into the access token.
>>>>>>
>>>>>>
>>>>>>    1. To ensure that the API Provider does not censor the client app
>>>>>>    that presents the capability or solicits too much information about the
>>>>>>    client app or the end-user of the client app.
>>>>>>
>>>>>>
>>>>>> This is one of the reasons that the AS-based model is really
>>>>>> important in GNAP — the API Provider's RS only needs to know “is this token
>>>>>> good for what’s being asked”.
>>>>>>
>>>>>>
>>>>>>    1. If the API Provider decides, for any reason, to be
>>>>>>    “suspicious” (as above) of the access transaction based on the information
>>>>>>    it has, it should be possible for the API Provider to warn the patient and
>>>>>>    to accept an override of the warning by the patient. This effectively means
>>>>>>    that the end-user will provide as much information as they think will be
>>>>>>    necessary in order to either avoid “suspicion” or risk waiting for patient
>>>>>>    override.
>>>>>>
>>>>>>
>>>>>> If the AS can reach out to the patient through notice and consent,
>>>>>> they can be brought into the process in an interactive way above. This
>>>>>> assumes the AS has a way of connecting that, but we should assume the AS
>>>>>> can provide this kind of notice and consent to parties that aren’t directly
>>>>>> involved in the protocol flow in the same way the end user is.
>>>>>>
>>>>>>
>>>>>>    1. The policies by which the patient or the decides to grant a
>>>>>>    capability to the requesting party are never shared outside of the
>>>>>>    patient-agent trust relationship. In other words, neither the patient nor
>>>>>>    the agent is asked to share or explain their reason for an access decision.
>>>>>>
>>>>>>
>>>>>> In the above pattern, the AS and agent would need a way to
>>>>>> communicate this with each other. I think the details of this are outside
>>>>>> the scope of GNAP but it could take the form of a query/response
>>>>>> fulfillment language. VC’s address part of this, but I think there will
>>>>>> need to be other aspects brought to bear here. I think you could have a
>>>>>> privacy-preserving protocol that would layer into GNAP here, but I don’t
>>>>>> know for sure what that would look like.
>>>>>>
>>>>>>
>>>>>>    1. Access requests to the agent are presumed confidential among
>>>>>>    the patient, the agent, and whatever client the requesting party uses to
>>>>>>    present an access request. The API Provider does not get to see the
>>>>>>    requests and no entity in the GNAP authorization process, other than the
>>>>>>    patient or the agent, gets to correlate across requests by different
>>>>>>    requesting party clients.
>>>>>>
>>>>>>
>>>>>> This would be a different kind of model, where the client would act
>>>>>> as some kind of proxy in the process. Something more like:
>>>>>>
>>>>>> [image: https://www.websequencediagrams.com/?png=msc685845457]
>>>>>>
>>>>>> User -> Client: go access my medical data
>>>>>> Client -> RS: hey I want to access this medical data
>>>>>> RS -> Client: sure go talk to this AS
>>>>>> Client -> Agent: I need to make a request for data, how can I get the
>>>>>> AS in touch with you?
>>>>>> Agent -> Client: tell them to use [some kind of magic]
>>>>>> Client -> AS: hey I want to access this medical data; I can get the
>>>>>> user to interact with you or I can forward your request details to the
>>>>>> policy agent
>>>>>> AS -> Client: OK go talk to the policy agent, ask for these kinds of
>>>>>> things
>>>>>> Client -> Agent: I have a request for data, at this AS, I need you to
>>>>>> prove that you have the right to release this data
>>>>>> Agent -> User: It looks like Client is asking for stuff at RS through
>>>>>> AS, that cool?
>>>>>> Agent -> Client: OK, here you go [more magic]
>>>>>> Client -> AS: Here’s the result of that policy thing you asked for
>>>>>> [more magic]
>>>>>> AS -> Client: ok, here’s an access token that’s good for accessing
>>>>>> that AS
>>>>>> Client -> RS: hey, I want to access this medical data and here’s an
>>>>>> access token for it
>>>>>>
>>>>>>
>>>>>>
>>>>>> Note that I am not saying all 8 requirements are in scope for GNAP
>>>>>> but I am asking for GNAP to allow for this level of privacy on the part of
>>>>>> self-sovereign patients using self-sovereign agents and the self-sovereign
>>>>>> licensed professionals they deal with.
>>>>>>
>>>>>>
>>>>>> For me the important part is that GNAP allow these kinds of trust
>>>>>> connections. Even if GNAP isn’t solving every piece of this equation, it
>>>>>> can at least clearly state “there’s a function here that needs to / is able
>>>>>> to solve this thing” and build the important parts around it.
>>>>>>
>>>>>>
>>>>>>  - Justin
>>>>>>
>>>>>>
>>>>>> Adrian
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault <
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>> Hi Justin,
>>>>>>>
>>>>>>> Just a quick word to say I very much agree with both the
>>>>>>> observations and the framing.
>>>>>>>
>>>>>>> Fabien
>>>>>>>
>>>>>>> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> As discussed at the IETF meeting, the editors proposed that one of
>>>>>>>> our next big topic areas was going to be the nature of the AS role within
>>>>>>>> the GNAP protocol, especially how it relates to the device-driven use cases
>>>>>>>> that have been brought up. Apologies in advance for the long post, but
>>>>>>>> there are a lot of parts to this discussion that I’m hoping we can kick off
>>>>>>>> here.
>>>>>>>>
>>>>>>>> My core proposal is that we see the AS as the component that has
>>>>>>>> the following properties:
>>>>>>>>  - receives delegation requests from the client instance for access
>>>>>>>> to an RS via access tokens, and for access to subject information returned
>>>>>>>> directly to the client instance
>>>>>>>>  - collects consent and authorization from the RO for the delegation
>>>>>>>>  - issues access tokens that its downstream RS’s can interpret (and
>>>>>>>> validate/accept)
>>>>>>>>  - issues subject information asserted by the AS
>>>>>>>>
>>>>>>>> This framing of the parties is really important in making a
>>>>>>>> consistent understanding of how the protocol works, and a consistent
>>>>>>>> understanding is vital if we’re going to function as a working group in
>>>>>>>> both discussing the problem space and executing the solution space. For a
>>>>>>>> historical example, a naive approach to adding identity on top of a
>>>>>>>> protocol like OAuth 2 (or GNAP) is to declare that the resource server is
>>>>>>>> the thing the user is logging in to. This seems reasonable at first (and
>>>>>>>> some people tried doing this) but it violates all kinds of trust boundaries
>>>>>>>> and puts new expectations on the different parties that do not make sense.
>>>>>>>> It stops looking anything like OAuth very quickly and turns into another
>>>>>>>> protocol. If instead we say the user is logging in to the client, things
>>>>>>>> suddenly make a lot more sense and we can do a lot more with it. (See this
>>>>>>>> blog post from 2013 for one take on that discussion:
>>>>>>>> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/
>>>>>>>> )
>>>>>>>>
>>>>>>>> I think we’ve got a similar situation here when we start to talk
>>>>>>>> about the user bringing their own AS with them. I think this is a
>>>>>>>> reasonable-seeming assumption but it’s based on a false premise that the RO
>>>>>>>> has to log into the AS to approve the request, and the AS has full control
>>>>>>>> and view over everything in the network. While OAuth doesn’t require this,
>>>>>>>> it’s largely assumed that’s how it works. After all, all of the early OAuth
>>>>>>>> deployments worked exactly this way: the user logs in and clicks the “OK”
>>>>>>>> button. However, cloud deployments have shown us that it’s perfectly
>>>>>>>> reasonable for an OAuth AS to take in its consent and user information from
>>>>>>>> an external trusted source, and so this model is not even accurate in OAuth.
>>>>>>>>
>>>>>>>> In short, I think we can do a better job here of defining things in
>>>>>>>> terms that both accept the reality we face and enable new ideas in ways
>>>>>>>> that make sense. It’s my stance that the user shouldn’t need to bring the
>>>>>>>> AS with them in order to have the kind of input and control of the system
>>>>>>>> that people are asking for. Instead, the AS should be able to take inputs
>>>>>>>> from things that the user controls in order for the AS to do its job.
>>>>>>>>
>>>>>>>> People have discussed privacy concerns with the AS knowing “too
>>>>>>>> much”, but in many of those discussions the knowledge is simply pushed to
>>>>>>>> the RS instead. What I’m observing here is really just pushing portions of
>>>>>>>> the AS role into the “RS” deployment. This doesn’t make it less of an “AS”
>>>>>>>> role, it’s just being fulfilled closely to where the RS role is fulfilled.
>>>>>>>> As such, my proposal is really not that different in practice, but the
>>>>>>>> labels are different and better aligned with the capabilities of the
>>>>>>>> protocol.
>>>>>>>>
>>>>>>>> We’ve previously talked about separating the user-facing portions
>>>>>>>> of the AS into another component, and I think now might be the time to do
>>>>>>>> that. This is a very flammable strawman proposal, but what if we had the AS
>>>>>>>> defined, as above, and the “consent and authorization” gathering portion is
>>>>>>>> augmented by another named component. Here let’s call it an Interaction
>>>>>>>> Component. This can take several forms based on the kind of interaction
>>>>>>>> mode in use:
>>>>>>>>
>>>>>>>>  - Hosted at a URL the user is redirected to; it can then make the
>>>>>>>> user log in, consent, and whatever else they need to do
>>>>>>>>  - Hosted at a URL the user will load separately and enter in an
>>>>>>>> access code
>>>>>>>>  - An app on the user’s device that the user interacts with
>>>>>>>> directly and which sends information back to the AS
>>>>>>>>  - An app reachable by a messaging endpoint that the AS sends and
>>>>>>>> receives structured information from
>>>>>>>>  - The client itself that is given an indication as to what
>>>>>>>> information the AS needs in order to fulfill the request; this could be MFA
>>>>>>>> challenge/response, user credentials, signed claims, etc.
>>>>>>>>
>>>>>>>> It’s the AS’s job to accept any and all of these that it supports
>>>>>>>> and churn those into an access token.
>>>>>>>>
>>>>>>>> The AS itself doesn’t ever need to have the user log in. The AS
>>>>>>>> doesn’t necessarily need to even know who the user is in any way. The AS
>>>>>>>> just needs to know from a trusted source that the request is approved.
>>>>>>>>
>>>>>>>> From a practical standpoint, I think this will have some small
>>>>>>>> changes in how we talk about the components and how we talk about the
>>>>>>>> interaction phase of the grant negotiation process. Everything I’m laying
>>>>>>>> out here is currently allowed by the spec, but I think we’ve carried
>>>>>>>> through the same assumptions from OAuth 2 about deployment that are both
>>>>>>>> inaccurate and confusing.
>>>>>>>>
>>>>>>>>  — Justin
>>>>>>>> --
>>>>>>>> TXAuth mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>>
>>>>>>> --
>>>>>>> TXAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>
>>>>>> --
>>>>> TXAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>>
>>> --
>> TXAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>>