Re: Human rights perspective on W3C and IETF protocol interaction

Thanks for your reply Justin, I'm loosely familiar with IETF, having seen HTTP
Signatures work expire before
<https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12>...
(same status type)... vs https://datatracker.ietf.org/doc/html/rfc9162 (does
not expire).

You stated that the document is incorrectly labeled:

> Also a note about IETF process for the W3C folks that this document is
not simply an “internet-draft” from an individual (which has about as much
weight as a web-page) but an active document of an active working group,
and as such has more normative standards weight than any Note the CCG is
allowed to produce within the W3C.

Am I linking to the incorrect place here?

[image: Screen Shot 2022-01-05 at 4.43.41 PM.png]

> The choice of a service to delegate login — which GNAP does not define —
is the choice of that service.
> And in fact, the loss of services is exactly the kind of thing that, I
believe, Adrian is asking about.

Yes, this is my exact point...(sorry if the humor didn't land properly).

You seem to be asserting that GNAP does not protect against loss of
services (clearly OAuth does not).

Adrian seems to be asserting that loss of an issuer service is a threat to
human rights.... My point is that suggesting GNAP is a solution to this
problem is incorrect in the same way you pointed out that conflating
federated identity and delegated access is incorrect.... or to put the
entire thing in terms of GNAP.... GNAP does not protect against loss of
GNAP authorization servers... GNAP users are vulnerable (in the same sense
that OAuth users are) to loss of authorization servers... If I am getting
this wrong, and GNAP supports decentralized authorization servers that are
uncensorable, please explain how that works, because that sounds awesome...
and similar to a blockchain :)

I am attempting to learn the answer to the same question Bob asked:

> Could you please explain how CCG's adoption of GNAP would facilitate "a
focus on human rights as a design principle" (i.e. the goal you stated in
your original message)

Based on what Justin has said so far, it seems like the answer is no,
protocols do not solve human rights problems, especially ones associated
with issuer's revoking or refreshing credentials, or Verifiers / RPs acting
in bad faith.... or any of the other issues discussed here:
https://w3c.github.io/vc-data-model/#privacy-considerations

Since GNAP and OAuth are both equally incapable of compelling an issuer
(like twitter, or the US Gov), or verifiers (... like Login.gov, Auth0 /
Okta, or other proud operators of OAuth Authorization Servers), or RPs
(verifiers who are resource server operators) to enforce human rights.

However, GNAP has learned from OAuth (and its many failings), and as Justin
pointed out, the core document is the current focus of the working group at
IETF...

[image: Screen Shot 2022-01-05 at 5.17.27 PM.png]
(Same status, expires in April ). -- side note, I wish W3C did the same
thing, expiring things seems like a best practice.

This section seems to speak to the question Bob and I were asking...

> The role of the authorization server is to manage the authorization of
client instances to protect access to the user's data. In this role, the
authorization server is by definition aware of each authorization of a
client instance by a user. When the authorization server shares user
information with the client instance, it needs to make sure that it has the
permission from that user to do so.

> Additionally, as part of the authorization grant process, the
authorization server may be aware of which resource servers the client
intends to use an access token at.

> If the authorization server's implementation of access tokens is such
that it requires a resource server call back to the authorization server to
validate them, then the authorization server will be aware of which
resource servers are actively in use and by which users and which clients.
To avoid this possibility, the authorization server would need to structure
access tokens in such a way that they can be validated by the resource
server without notifying the authorization server that the token is being
validated.

-  <goog_1480019720>
https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-08.html#name-privacy-considerations

To me, this section of the GNAP spec sounds very familiar.... to this
section of the VC Data Model...

> As detailed in Section § 7.13 Usage Patterns
<https://w3c.github.io/vc-data-model/#usage-patterns>, usage patterns can
be correlated into certain types of behavior. Part of this correlation is
mitigated when a holder <https://w3c.github.io/vc-data-model/#dfn-holders> uses
a verifiable credential
<https://w3c.github.io/vc-data-model/#dfn-verifiable-credentials> without
the knowledge of the issuer
<https://w3c.github.io/vc-data-model/#dfn-issuers>. Issuers
<https://w3c.github.io/vc-data-model/#dfn-issuers> can defeat this
protection however, by making their verifiable credentials
<https://w3c.github.io/vc-data-model/#dfn-verifiable-credentials> short
lived and renewal automatic.

> For example, an ageOver verifiable credential
<https://w3c.github.io/vc-data-model/#dfn-verifiable-credentials> is useful
for gaining access to a bar. If an issuer
<https://w3c.github.io/vc-data-model/#dfn-issuers> issues such a verifiable
credential <https://w3c.github.io/vc-data-model/#dfn-verifiable-credentials>
with
a very short expiration date and an automatic renewal mechanism, then the
issuer <https://w3c.github.io/vc-data-model/#dfn-issuers> could possibly
correlate the behavior of the holder
<https://w3c.github.io/vc-data-model/#dfn-holders> in a way that negatively
impacts the holder <https://w3c.github.io/vc-data-model/#dfn-holders>.

> Organizations providing software to holders
<https://w3c.github.io/vc-data-model/#dfn-holders> should warn them if they
repeatedly use credentials
<https://w3c.github.io/vc-data-model/#dfn-credential> with short lifespans,
which could result in behavior correlation. Issuers
<https://w3c.github.io/vc-data-model/#dfn-issuers> should avoid issuing
credentials <https://w3c.github.io/vc-data-model/#dfn-credential> in a way
that enables them to correlate usage patterns.
- https://w3c.github.io/vc-data-model/#frequency-of-claim-issuance

Another reference:

> An application currently utilizing OpenID Connect for accessing various
federated identity providers can use the same protocol to also integrate
with emerging SSI-based wallets. This is a convenient transition path
leveraging existing expertise to protect investments made.

-
https://openid.net/2021/12/17/first-public-review-period-for-openid-connect-siopv2-and-oidc4vp-specifications-started/
-
https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0-07.html
The questions Adrian is asking regarding human rights apply to GNAP, OAuth,
OIDC and the VC Data Model.

The question remains which protocol is "best for human rights"... OIDC,
OAuth, GNAP ?
I hope they keep competing with each other for that title...

Lets not feed the trolls by taking their bait of "Bitcoin is the only
solution to human rights issues" or "OIDC is the only solution to human
rights issues"...
These kinds of moral statements are divisive and unwinnable.

Lets avoid maximalist perspectives and embrace the fact that diversity is a
security property.

I encourage folks interested in contributing to GNAP to join the IETF WG,
interested in OIDC? Join the OIDF, etc...

The "best protocol for defending human rights" is an observable property of
successfully served users.

Cheers,

OS
ᐧ

On Wed, Jan 5, 2022 at 4:33 PM Justin Richer <jricher@mit.edu> wrote:

> Federated identity and delegated access are separate concerns, please be
> careful not to conflate them. The choice of a service to delegate login —
> which GNAP does not define — is the choice of that service.
>
> And in fact, the loss of services is exactly the kind of thing that, I
> believe, Adrian is asking about. In GNAP core, we improve this over OAuth
> by moving away from the “go to a web page on the AS” assumptions and
> allowing a more nuanced and varied means of interaction and consent.
> Technologies like VC fit really well here: if I can present a VC to the AS,
> then the AS doesn’t need to “log me in” in a traditional OAuth sense.
>
>
> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-08.html#name-determining-authorization-a
>
> As I’ve explained on several DID, VCAPI, and related calls so far, this
> connection inbound to the AS is one of the most important ways that these
> items can be connected. If I have an accepted and standard way to get my
> consent, rights, and attributes into the AS without the AS needing me to
> make an account and log in, the more distributed the end system ends up
> being :without: requiring an RS to accept tokens from an arbitrary AS. We
> know from past attempts that this latter request is a bridge too far for
> nearly every RS. Getting the AS to accept external inputs and interactions,
> however, is a well-established pattern that GNAP is codifying and making
> explicitly extensible.
>
> Also a note about IETF process for the W3C folks that this document is not
> simply an “internet-draft” from an individual (which has about as much
> weight as a web-page) but an active document of an active working group,
> and as such has more normative standards weight than any Note the CCG is
> allowed to produce within the W3C. This is not to disparage the CCG at all,
> but just to point out that there are different classes of work here, and
> it’s easy to confuse the two.
>
> Also since this seems to be confusing, the expiration date is an artifact
> of the group currently focusing on the core document, and as discussed
> publicly at the WG meetings, the resource server document is next on the
> queue. As I’m sure you are aware yourself, Orie, there are only so many
> cycles that a group can apply to work in progress and be effective. It is
> not an indication that the WG has abandoned or plans to abandon the
> resource servers draft.
>
>  — Justin
>
> On Jan 5, 2022, at 5:12 PM, Orie Steele <orie@transmute.industries> wrote:
>
> I wonder how many services President Trump lost access to when they banned
> his twitter account.
>
> Can someone explain how GNAP improves on OAuth in this regard?
>
> I can't find anything here:
> https://datatracker.ietf.org/doc/html/draft-ietf-gnap-resource-servers#section-7
>
> Also heads up that this "Internet-Draft" of "Intended status: Standards
> Track" expires on 13 January 2022.
>
>
> OS
>
>
> ᐧ
>
> On Wed, Jan 5, 2022 at 3:46 PM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> Bob,
>> The design principle is Separation of Concerns (separating control from
>> possession).
>>
>> The human rights issue is to mitigate the often absolute sovereignty of
>> the Issuer by making it obvious in both the technical and the regulatory
>> sense when the Issuer is reducing the capacity or choice of the Subject
>> through mandates like OAuth client credentials. GNAP, as opposed to OAuth,
>> makes it very obvious when delegation is restricted without justification.
>> As such, it will tend to keep the Issuers more honest and make them more
>> transparent and easier to judge in terms of human rights.
>>
>> Adrian
>>
>> On Wed, Jan 5, 2022 at 4:26 PM Bob Wyman <bob@wyman.us> wrote:
>>
>>> Adrian,
>>> I'm confused by your latest comments. Could you please explain how CCG's
>>> adoption of GNAP would facilitate "a focus on human rights as a design
>>> principle" (i.e. the goal you stated in your original message) Please
>>> forgive me if I'm missing something important in what you've said.
>>>
>>> bob wyman
>>>
>>>
>>> On Wed, Jan 5, 2022 at 3:57 PM Adrian Gropper <agropper@healthurl.com>
>>> wrote:
>>>
>>>> In this thread, my focus is the relationship between CCG and GNAP. RFCs
>>>> are considered in the broader context of an Internet security layer such as
>>>> Sam Smith and KERI are addressing. My proposal is that CCG will be
>>>> well-served by adopting GNAP (and RAR) in as many protocol efforts as it
>>>> can. If CCG does not outsource some protocol concerns to GNAP and other
>>>> RFCs, then I believe other groups will bypass CCG-related protocols as we
>>>> are already seeing in EU and ISO with mDL.
>>>>
>>>> The VC and DID work on data models and related registries is valuable
>>>> with or without CCG protocol tie-ins. If I were to suggest a formal CCG
>>>> work item, it would be to develop which specific authorization and
>>>> authentication protocols should be layered on top of GNAP and RAR.
>>>>
>>>> Adrian
>>>>
>>>> On Wed, Jan 5, 2022 at 2:53 PM Alan Karp <alanhkarp@gmail.com> wrote:
>>>>
>>>>> RFCs have a Security Considerations section.  Are you suggesting that
>>>>> these groups include a Human Rights Considerations section in addition?
>>>>>
>>>>> --------------
>>>>> Alan Karp
>>>>>
>>>>>
>>>>> On Wed, Jan 5, 2022 at 7:14 AM Adrian Gropper <agropper@healthurl.com>
>>>>> wrote:
>>>>>
>>>>>> Bob's are important questions in the context of our specific protocol
>>>>>> work. I do not mean to scope this thread to general W3C or IETF groups or
>>>>>> their governance. *Bold* is used below to link to Bob's specific
>>>>>> questions.
>>>>>>
>>>>>> I might also argue to limit the scope to protocols and not VC, DID,
>>>>>> biometric templates, or other data models even though effective standards
>>>>>> for these drive quantitative and possibly qualitative improvements in the
>>>>>> efficiency of surveillance because a common language seems essential to
>>>>>> discussing protocols. Adverse consequences of the efficiency of common
>>>>>> interoperable language can be mitigated at the protocol level.
>>>>>>
>>>>>> I'm responding in personal terms to Bob's questions. *I urge all of
>>>>>> us engaged in the protocol engineering effort to bring their own
>>>>>> perspective on "Human Rights" and to advocate for specific technical
>>>>>> solutions in specific workgroups.* For example, I have chosen to
>>>>>> focus attention on authorization for verifiable credential issue. I hope
>>>>>> others will prioritize human rights impact of authentication protocols
>>>>>> especially where biometrics could be involved.
>>>>>>
>>>>>> *The specific aspects of our protocol work that give rise to human
>>>>>> rights issues relate to the efficiency of standardized digital credentials
>>>>>> to human persons.* What works for drugs in a supply chain or cattle
>>>>>> on a farm can and usually will be misused on people. Also, transferring
>>>>>> responsibility from an issuer to a subject of a VC is a burden that needs
>>>>>> to be recognized and mitigated. With respect to the UDHRs, I would point to
>>>>>> 12 (privacy and confidentiality), 13 (anonymity), 14 (limit the reach of
>>>>>> DHS and other state actors), 17 (the right to associate with and delegate
>>>>>> to others), 18 (associate with and delegate to communities one chooses), 20
>>>>>> (association, again), 21 (secret elections), 22 (anonymity), 23 (trade
>>>>>> unions as delegates), 24 (burden of managing decisions in an asymmetric
>>>>>> power relationship with the state or with dominant private platforms), 29
>>>>>> (duties to and scope of the community).
>>>>>>
>>>>>> *I'm suggesting that we formally address the issue of human rights as
>>>>>> applied to the VC-API standardization process.* I'm also suggesting
>>>>>> that we use a process in VC-API that formally harmonizes our work with IETF
>>>>>> GNAP.
>>>>>>
>>>>>> Adrian
>>>>>>
>>>>>> On Tue, Jan 4, 2022 at 11:45 PM Bob Wyman <bob@wyman.us> wrote:
>>>>>>
>>>>>>> Adrian,
>>>>>>> Given that you're starting a new thread, I would appreciate it if
>>>>>>> you could do some context setting and clarifying:
>>>>>>>
>>>>>>>    - *What do you mean by "Human Rights?" *Hopefully, you won't
>>>>>>>    consider that a foolish question. The issue is, of course, that since
>>>>>>>    Internet standards are developed in a multicultural, multinational context,
>>>>>>>    it isn't obvious, without reference to some external authority, what a
>>>>>>>    standards group should classify as a human right. Different cultures and
>>>>>>>    governments tend to differ on this subject... As far as I know, the "best"
>>>>>>>    source of what might be considered a broad consensus definition of human
>>>>>>>    rights is found in the UN's 1948 Universal Declaration of Human
>>>>>>>    Rights
>>>>>>>    <https://www.un.org/en/about-us/universal-declaration-of-human-rights>
>>>>>>>     (UDHR).
>>>>>>>       - Does the UDHR contain the full set of rights that you think
>>>>>>>       should be addressed by standards groups? If not, are there additional
>>>>>>>       rights that you think should be considered?
>>>>>>>       - In his document, Human Rights Are Not a Bug
>>>>>>>       <https://www.fordfoundation.org/work/learning/research-reports/human-rights-are-not-a-bug-upgrading-governance-for-an-equitable-internet/>,
>>>>>>>       Niels ten Oever refers to the UN Guiding Principles for
>>>>>>>       Business and Human Rights
>>>>>>>       <https://www.ohchr.org/documents/publications/guidingprinciplesbusinesshr_en.pdf>,
>>>>>>>       which adds to the rights enumerated in the UDHR a number of additional
>>>>>>>       rights described in the International Labour Organization’s Declaration
>>>>>>>       on Fundamental Principles and Rights at Work
>>>>>>>       <https://www.ilo.org/declaration/lang--en/index.htm>. Given
>>>>>>>       that you appear to endorse ten Oever's report, do you also propose the same
>>>>>>>       combined set of rights? (ie. UDHR + ILO DFPRW?)
>>>>>>>       - Some have argued that the Internet introduces a need to
>>>>>>>       recognize rights that have not yet been enumerated either in the UDHR or in
>>>>>>>       any other broadly accepted documents. If this is the case, how is a
>>>>>>>       standards group to determine what set of rights they must respect?
>>>>>>>    - *What specific aspects of the issues being addressed by this
>>>>>>>    community group give rise to human rights issues?* Also, if you
>>>>>>>    accept that one or some number of documents contain a useful list of such
>>>>>>>    rights, can you identify which specific, enumerated rights are at risk?
>>>>>>>    (e.g. if the UDHR is the foundation text, then I assume privacy issues
>>>>>>>    would probably be considered in the context of the UDHR's Article
>>>>>>>    12
>>>>>>>    <https://www.un.org/en/about-us/universal-declaration-of-human-rights#:~:text=Article%2012,interference%20or%20attacks.>
>>>>>>>    .)
>>>>>>>    - *Are you suggesting that this group should formally address
>>>>>>>    the issue of rights*, with some sort of process, or just that we
>>>>>>>    should be aware of the issues?
>>>>>>>       - ten Oever suggests that "Those who design, standardize, and
>>>>>>>       maintain the infrastructure on which we run our information societies,
>>>>>>>       should assess their actions, processes, and technologies on their societal
>>>>>>>       impact." You apparently agree. Can you say how this should be done?
>>>>>>>       - The UN Guiding Principles for Business and Human Rights
>>>>>>>       describe a number of procedural steps that should be taken by either
>>>>>>>       governments or corporations. Are you aware of a similar procedural
>>>>>>>       description that would apply to standards groups?
>>>>>>>       - I think it was in the video that it was suggested that, in
>>>>>>>       Internet standards documents, "a section on human rights considerations
>>>>>>>       should become as normal as one on security considerations." Do you agree?
>>>>>>>       If so, can you suggest how such a section would be written?
>>>>>>>
>>>>>>> bob wyman
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 4, 2022 at 9:05 PM Adrian Gropper <
>>>>>>> agropper@healthurl.com> wrote:
>>>>>>>
>>>>>>>> This is a new thread for a new year to inspire deeper cooperation
>>>>>>>> between W3C and IETF. This is relevant to our formal objection issues in
>>>>>>>> W3C DID as well as the harmonization of IETF SECEVENT DIDs and GNAP with
>>>>>>>> ongoing protocol work in W3C and DIF.
>>>>>>>>
>>>>>>>> The Ford Foundation paper attached provides the references.
>>>>>>>> However, this thread should not be about governance philosophy but rather a
>>>>>>>> focus on human rights as a design principle as we all work on protocols
>>>>>>>> that will drive adoption of W3C VCs and DIDs at Internet scale.
>>>>>>>>
>>>>>>>> https://redecentralize.org/redigest/2021/08/ says:
>>>>>>>>
>>>>>>>> *Human rights are not a bug*
>>>>>>>>> Decisions made by engineers in internet standards bodies (such as
>>>>>>>>> IETF <https://www.ietf.org/> and W3C <https://www.w3.org/>) have
>>>>>>>>> a large influence on internet technology, which in turn influences people’s
>>>>>>>>> lives — people whose needs may or may not have been taken into account. In
>>>>>>>>> the report Human Rights Are Not a Bug
>>>>>>>>> <https://www.fordfoundation.org/work/learning/research-reports/human-rights-are-not-a-bug-upgrading-governance-for-an-equitable-internet/>
>>>>>>>>>  (see also its launch event
>>>>>>>>> <https://www.youtube.com/embed/qyYETzXJqmc?rel=0&iv_load_policy=3&modestbranding=1&autoplay=1>),
>>>>>>>>> Niels ten Oever asks *“how internet governance processes could be
>>>>>>>>> updated to deeply embed the public interest in governance decisions and in
>>>>>>>>> decision-making culture”*.
>>>>>>>>> “Internet governance organizations maintain a distinct governance
>>>>>>>>> philosophy: to be consensus-driven and resistant to centralized
>>>>>>>>> institutional authority over the internet. But these fundamental values
>>>>>>>>> have limitations that leave the public interest dangerously neglected in
>>>>>>>>> governance processes. In this consensus culture, the lack of institutional
>>>>>>>>> authority grants disproportionate power to the dominant corporate
>>>>>>>>> participants. While the governance bodies are open to non-industry members,
>>>>>>>>> they are essentially forums for voluntary industry self-regulation. Voices
>>>>>>>>> advocating for the public interest are at best limited and at worst absent.”
>>>>>>>>> The report describes how standards bodies, IETF in particular,
>>>>>>>>> focus narrowly on facilitating interconnection between systems, so that
>>>>>>>>>  *“many rights-related topics such as privacy, free expression or
>>>>>>>>> exclusion are deemed “too political””*; this came hand in hand
>>>>>>>>> with the culture of techno-optimism:
>>>>>>>>> “There was a deeply entrenched assumption that the internet is an
>>>>>>>>> engine for good—that interconnection and rough consensus naturally promote
>>>>>>>>> democratization and that the open, distributed design of the network can by
>>>>>>>>> itself limit the concentration of power into oligopolies.
>>>>>>>>> This has not proved to be the case.”
>>>>>>>>> To improve internet governance, the report recommends involving
>>>>>>>>> all stakeholders in decision procedures, and adopting human rights impact
>>>>>>>>> assessments (a section on *human rights considerations* should
>>>>>>>>> become as normal as one on *security considerations*).
>>>>>>>>> The report only briefly touches what seems an important point:
>>>>>>>>> that existing governance bodies may become altogether irrelevant as both
>>>>>>>>> tech giants and governments move on without them:
>>>>>>>>> “Transnational corporations and governments have the power to
>>>>>>>>> drive internet infrastructure without the existing governance bodies,
>>>>>>>>> through new technologies that set de facto standards and laws that govern
>>>>>>>>> “at” the internet not “with” it.”
>>>>>>>>> How much would having more diverse stakeholders around the table
>>>>>>>>> help, when ultimately Google decides whether and how a standard will be
>>>>>>>>> implemented, or founds a ‘more effective’ standardisation body instead?
>>>>>>>>
>>>>>>>>
>>>>>>>> Our work over the next few months is unbelievably important,
>>>>>>>>
>>>>>>>> - Adrian
>>>>>>>>
>>>>>>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries/>
>
>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>