Re: [hrpc] When are HRPCs normative in an IETF protocol?

[Adrian Gropper <[e-mail]>]

Thank you for concrete examples. Inline...

On Tue, Nov 29, 2022 at 8:36 AM Justin Richer <[e-mail]> wrote:

> We’re not trying to say you have to compromise between human rights and
> security. We’re saying you can fulfill the human rights concerns in a
> different way than what you’re proposing without compromising security.
> You’re making a false comparison between the two, and we’ve been trying to
> show that it’s not an either-or.
>
> And to the statement below: if I show up to an AS with a verifiable
> credential that says “this person is a doctor in that hospital over there”
> and the AS has a policy that says “any doctor at that hospital can view all
> X-rays”, then the AS can easily grant an access token that says “this token
> is good for viewing this x-ray”. At no point here does the AS know the
> identity of the doctor. At no point does the RS need to know anything about
> doctors at all.
>

This is exactly the use-case I've been working on and testifying about for
over a decade in HL7 FHIR, Kantara UMA, OpenID HEART and the W3C VC
workgroups. Traditional health information exchange is an example of "One
set of policies applies to all patients and clinicians unless the patient
has requested an exception." This is also roughly analogous to Facebook
(mostly secret) or Twitter (somewhat secret) resource access policies for
who sees what.

It's the "the AS can easily grant" where the problems of Information
Blocking or unintended extremism come in. In practice, essentially zero
patients navigate the system to enter an HIE exception. The doctors also
struggle with exceptions when their practice style doesn't include
employment by a major institution. When it comes to humans, handling the
exceptions is the essence of avoiding forced association.

Handling the exceptions isn't free to the resource service provider but it
doesn't have to be expensive or hard. GNAP already fixes many of the
problems that make OAuth "hard" like, for example, dealing with an end user
that doesn't have a browser as their user agent.

To avoid forced association of human subjects of a resource server the RS
or AS needs a way to flag that an exception to the baseline policies (be
they open or secret) has been requested for a specific resource that is
associated with a human subject. Almost universally, a service managing
human-subject resources has a list of the humans. In healthcare and beyond
these are increasingly a mobile phone number. Email addresses are second.
Adding a policy exception flag to that list is trivial. Whether the list of
humans and exceptions is kept by the RS or AS is irrelevant to my
perspective and I accept that GNAP prefers to have the AS keep a list of
humans and the RS keeps the list of resources. The separation of resource
processing from control of the resource processing is helpful and should be
encouraged.


> This is the kind of system that GNAP enables people to build. Extending
> this system to allow a patient to say “and let my partner see my x-ray”
> means we have to allow the patient to express how someone fulfills “my
> partner” to the AS. In most AS’s, especially in OAuth, this means you name
> a specific account. This is the google docs example you gave. But it could
> be any wide number of things that the AS can use to make that call that any
> particular end-user fulfills the policy.
>

Exactly. So the AS has a way for human subjects to request an exception to
the RS+AS policies. The question for GNAP is how that flag is handled.

It could be handled by the RS+AS offering to process more or less arbitrary
policies (very very hard) or it could be handled through delegated
authorization (which is what GNAP claims to be).

Discussions on the GNAP list have raised three possible ways to handle the
exceptions.
1 - Allow the human subject (RO) requesting the exception to point to an AS
they choose.
2 - Avoiding the exception flag altogether by issuing every RO a capability
associated with the resource that the human can pass on to their chosen
GNAP AS for attenuation.
3 - Specifying a token exchange endpoint at the AS where another AS acting
as a delegate of the RO can request an attenuated token.

My request to the GNAP WG is that they specify at least one of these three
as normative for human rights reasons. Any of them would avoid the forced
association problem and allow any human subject to manage policies if they
choose. Policy management at GNAP AS is already out of scope and can stay
that way.

>
> That policy is at the AS and the AS is still tightly tied to the RS,
> without creating a forced association in the way you’ve described in the
> problem statement and without requiring the RS to allow the patient to
> specify their own AS at runtime in the way you’ve described in your
> solution statement.
>

This is where we seem to diverge. One AS as a token factory can respect
that another AS is also a token factory by design and by default. This is
the normative change I'm requesting. This is the principle that can give
regulators a handle on hyperscale platforms.

>
> GNAP AS a protocol cannot force an AS to have any particular policy. What
> can is regulation telling the x-ray lab to allow patients to specify a
> policy that can be fulfilled by people without accounts on the lab’s AS.
> That is actionable and auditable regulation, but it is not a protocol
> concern, especially not for GNAP in the general case.
>

Yes. I already agreed that policy management is out of scope for GNAP.

A request to the RS+AS does not have to be signed by someone with an
account at the AS. The only accounts the AS needs to track are RO accounts
and these are absolutely necessary if we are to allow exceptions and avoid
forced association.

For scalability, security, privacy, AND human rights, A request to _ANY_
GNAP AS can be tied to the ability to hold the requesting party (GNAP End
User) accountable. For example, a VC presented  as part of the request
might be sufficient relative to policy at that AS. No account needed. A
credential that secures the right to raise an exception or delete the
resource is also required in order to protect the Resource Server from
frivolous challenges. That's part of AS policy no matter what.

Adrian

>
>  — Justin
>
> On Nov 29, 2022, at 8:24 AM, Adrian Gropper <[e-mail]>
> wrote:
>
> Fabien,
>
> When requested, I have provided examples from healthcare, social media,
> GDPR, and other human-focused resources that are the major regulatory and
> privacy problems with the internet today.
>
> I know that Justin and you have world class experience with internet
> security and standards but can you try to respond to my arguments with
> examples of significant problems that cause compromise between security and
> human rights or use-cases that highlight how the tech problems of today
> will be addressed by GNAP?
>
> Adrian
>
> On Tue, Nov 29, 2022 at 1:03 AM Fabien Imbault <[e-mail]>
> wrote:
>
>> Adrian,
>>
>> The fact that you find security and privacy considerations for GNAP is a
>> testament that you can't draw the line as you do (even if you intend it as
>> a simplified example).
>>
>> Also the AS might use policies (esp. in a corporate environment), but
>> doesn't need to in the general case. It might just act based on the "type"
>> of negotiation and some decision logic separate from identity. I think
>> that's a fairly different design compared to oauth2/oidc.
>>
>> Fabien
>>
>>
>> On Tue, 29 Nov 2022, 04:53 Adrian Gropper, <[e-mail]>
>> wrote:
>>
>>> On Mon, Nov 28, 2022 at 8:32 PM Justin Richer <[e-mail]> wrote:
>>>
>>>> It is absolutely not doubling down, it is pointing out that the line is
>>>> drawn differently from where you are claiming it must be drawn.
>>>>
>>>> That difference is deeply important.
>>>>
>>>> That AS protecting an RS is a token factory. A regulatory body can
>>>> force a kind of or instance of AS to take inputs, including external
>>>> accounts, credentials, and policies, to create tokens for the RS’s it
>>>> protects.
>>>>
>>>> The AS doesn’t even need to know “who” the RO is anymore.
>>>>
>>>
>>> I find that last statement confusing. To act as a "token factory" for
>>> some RS, the AS must have policies specific to each RO. Google Docs AS has
>>> a list of people managed by the "owner". Twitter AS has a list of followers
>>> specific to an account. The RS only needs to know a scope associated with a
>>> token.
>>>
>>> The line I'm trying to draw is the same as GDPR Processor (as RS) and
>>> GDPR Controller (as AS). To oversimplify, the GDPR Processor has only
>>> security responsibility whereas the GDPR Controller has all privacy
>>> responsibility and it's security responsibility might be significantly less
>>> than the processor because the AS does not need to store or even see the
>>> resource itself - just the policies that it can use to issue tokens.
>>>
>>> How does GNAP draw the Processor / Controller line differently and why?
>>>
>>> Adrian
>>>
>>>
>>>
>>>
>>>>  — Justin
>>>>
>>>> On Nov 28, 2022, at 8:27 PM, Adrian Gropper <[e-mail]>
>>>> wrote:
>>>>
>>>> I read Justin's comment as doubling down on forced association.
>>>>
>>>> Protecting a resource that pertains to only one human subject does not
>>>> require the subject to share policies and requests with the protector. The
>>>> protector (be they RS or bundled RS+AS) merely needs to ensure that
>>>> authorizations that apply to the one subject do not negatively impact other
>>>> subjects hosted by the resource server. This distinction was extensively
>>>> discussed in the US federal hearings where I was an invited expert and the
>>>> conclusion / strategy I'm describing above was eventually approved by the
>>>> committee. Years later, and after significant congressional frustration,
>>>> the Information Blocking regulations came out based in part on the result
>>>> of that committee's work.
>>>>
>>>> Forced association is admittedly more "efficient" than what I'm
>>>> proposing but that's not surprising. Most human rights are less "efficient"
>>>> than the alternatives of making the powerful more powerful.
>>>>
>>>> Adrian
>>>>
>>>> On Mon, Nov 28, 2022 at 7:32 PM Justin Richer <[e-mail]> wrote:
>>>>
>>>>> I would like to just point out that the “RS” talked about in the
>>>>> example here is not an “RS” in the GNAP definition. What’s called the RS
>>>>> below is actually a combination of a GNAP AS and RS — it’s the protected
>>>>> API and the security around it at a local level. The hospital doesn’t just
>>>>> run an RS, it runs an AS to protect, monitor, and audit that RS.
>>>>>
>>>>> This is just one reason why I think it’s vital not to get stuck on the
>>>>> “AS <-> RS connection” as the only mitigation, normative or otherwise. GNAP
>>>>> is very explicitly built to allow greater flexibility in how the AS makes
>>>>> its decisions as to who to give tokens to, and for what purpose — and this
>>>>> is where I believe the real power is. This is where we can get into
>>>>> delegation between people. This is where we can get into attenuation. This
>>>>> is where we can get into personal sovereignty. All of this is :input: to
>>>>> the AS, not replacement of the AS.
>>>>>
>>>>>  — Justin
>>>>>
>>>>> On Nov 28, 2022, at 6:35 PM, Adrian Gropper <[e-mail]>
>>>>> wrote:
>>>>>
>>>>> I agree that IETF can't stop an RS from doing anything. I also have
>>>>> more than a decade of experience with the issue of regulatory capture in
>>>>> this exact context. My experience includes extensive work on Kantara UMA,
>>>>> OpenID HEART, and invited testimony in Washington on this topic that
>>>>> current regulations call "Information Blocking" for directed access to
>>>>> health records. It's taken about a decade for government, in a totally
>>>>> bipartisan way, to figure out how to limit bad behavior by hospitals and
>>>>> their technology vendors. And, although the regulations are now final,
>>>>> enforcement is still to come. My position ith respect to GNAP is based on
>>>>> first-hand experience and implementation around OAuth and UMA in both the
>>>>> commercial hospital RS and government (Medicare) RS context.
>>>>>
>>>>> The "various stakeholders" that Fabien talks about include both
>>>>> regulators and the customers of IT products, patients and physicians have
>>>>> almost zero market power and are not considered stakeholders. I myself am
>>>>> self-funded and depend on volunteers for any example implementations.
>>>>> Information blocking regulation spent years developing what is hoped is an
>>>>> effective strategy for encouraging desired behavior by the IT vendors given
>>>>> that their customers were happy to hide their interest in exclusive deals
>>>>> and lack of transparency behind false dichotomies around security and
>>>>> privacy. Regulatory capture of standards continues as the industry picks
>>>>> and chooses which standards to develop and implement. As patients and
>>>>> physicians we still have practically no market power.
>>>>>
>>>>> What IETF and GNAP can do is make the regulator's job as easy as
>>>>> possible by being explicit, dare I say normative, in stating that there is
>>>>> no security compromise required in order to put resources under the control
>>>>> of the subject's agent. As standards engineers, we can allow for legitimate
>>>>> security exceptions just as health regulators allow for exceptions to the
>>>>> current information blocking rules. What we must avoid is making exceptions
>>>>> that apply to incompetent patients, for example, the reason to dilute
>>>>> control, through delegated authorization of the vast majority of the rest
>>>>> of us patients and physicians.
>>>>>
>>>>> Whether it's health or social media, control over personal information
>>>>> is being abused by powerful interests. Regulators and civil society need
>>>>> your help.
>>>>>
>>>>> Adrian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 28, 2022 at 5:13 PM Fabien Imbault <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> Sorry but this doesn't make much sense imho. No normative requirement
>>>>>> can stop a RS to embed its own AS if it wants / needs to.
>>>>>>
>>>>>> What we can do is alert the various stakeholders on the risks and
>>>>>> provide pragmatic solutions for vast majority of implementers that do care.
>>>>>>
>>>>>>
>>>>>> On Mon, 28 Nov 2022, 22:55 Adrian Gropper, <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 28, 2022 at 4:19 PM Alan Karp <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Mon, Nov 28, 2022 at 11:52 AM Justin Richer <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Adrian,
>>>>>>>>>
>>>>>>>>> The core consideration you have raised is about the association
>>>>>>>>> between the RS and the AS.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I don't think that's what Adrian is saying even though he keeps
>>>>>>>> using the term "AS."  I believe he just wants to be sure that the RO can
>>>>>>>> delegate authorizations to an agent of the RO's choosing.
>>>>>>>>
>>>>>>>
>>>>>>> It's not just that. In order to address the rise of hyperscale
>>>>>>> platforms, We need to ensure that any RS labeled GNAP does not offer any
>>>>>>> usability or convenience benefits for using a bundled AS as compared to a
>>>>>>> GNAP-standard request processing endpoint specified by the RO. History
>>>>>>> shows that surveillance (of RO policies and end-user requests) is typically
>>>>>>> traded for convenience and that privacy mitigations like "Notice and
>>>>>>> Consent" don't work. This is why a human rights approach is required to
>>>>>>> make the desired behavior the default behavior. This is also the reason I
>>>>>>> am pushing for normative treatment.
>>>>>>>
>>>>>>> Adrian
>>>>>>>
>>>>>> _______________________________________________
>>>>>> hrpc mailing list
>>>>>> [e-mail]
>>>>>> https://www.irtf.org/mailman/listinfo/hrpc
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>> hrpc mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/hrpc
>>
>
>