RE: looking for a specific use-case

A longer article: https://eprint.iacr.org/2016/411.pdf. The authors are VERY supportive of security and privacy.
They run a project (PEP)<https://pep.cs.ru.nl/> that aims to design, build and implement a system that can be used as a privacy friendly and secure data repository for medical research data. The latest post in their news archive<https://pep.cs.ru.nl/newsarchive.html> is from April 2020. A most remarkable post was in Feb 2020 where they mentioned that all data from the Personalized Parkinson Project have been moved to Google Cloud Storage.
Seems like this is serious stuff.
Rieks

From: Adrian Gropper <agropper@healthurl.com>
Sent: dinsdag 22 december 2020 00:26
To: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>
Cc: W3C Credentials CG (Public List) <public-credentials@w3.org>
Subject: Re: looking for a specific use-case

Thanks Rieks! I'm not a cryptographer either but there might be one or two on this list :-)

I think you nailed-it. I would love to see an analysis of DID, DIDauth, and same-domain identifiers (like FIDO2) in the context of our SSI standards. The paper you link is mercifully short. Any volunteers?

Adrian

PS - any updates on the Dutch project?

On Mon, Dec 21, 2020 at 12:56 PM Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>> wrote:
I myself am not a proficient cryptographer, but there are some articles by Verheul and Jacobs that talk about "polymorphic encryption and pseudonymisation in identity management<https://www.cs.ru.nl/B.Jacobs/PAPERS/naw5-2017-18-3-168.pdf>" that may point to a (partial) solution. Rieks

From: Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>
Sent: maandag 21 december 2020 15:10
To: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>>
Subject: Re: looking for a specific use-case

Yes. Your example of passports and DLs is apt when you consider RealID as the federal government need to put passports and state drivers licenses into the same context for DDI purposes.

The more interesting issues arise around biometrics. Can we avoid centralized biometrics like the FBI database? Who controls DDI? How is DDI linked to voting? How do we deal with non-biometric DDI from ambient surveillance data like the phone companies have? Can we use DDI “parties” and blockchains to decentralize DDI to some extent?

Adrian

On Mon, Dec 21, 2020 at 3:11 AM Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>> wrote:
In order to understand the precise meaning of 'de-duplicated identity' (DDI) let me try to phrase a criterion by which one can distinguish between what is, and what is not, a  DDI (when I use the verb 'identify', this means: selecting a single entity from a group of entities that I know to exist):

A DDI is data that can be used to identify a person (entity), such that if two arbitrary parties do so in arbitrary contexts and both succeed (implying they both know the referred-to entity), they will have identified one and the same person (entity). DNA or iris-based identifiers qualify as DDI according to this criterion. Passports and driving licenses would not qualify because they are not data – they are the bearers of data (which may include a DDI).

Does this definition capture your understanding of a DDI?

Rieks

From: Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>
Sent: zaterdag 19 december 2020 13:44
To: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>>
Subject: Re: looking for a specific use-case

No worries. Examples of de-duplicated identities are DNA or iris-based identifiers which then become the basis of a legal credential. They are used in licenses / credentials and reputation that might otherwise be subject to sybil attacks. E.g. if I get too many tickets on my MA driver's license, why can't I just get a license in NY? Or, why spies have multiple passports. Why some social networks insist on "real name" policies. These are all examples of de-duplicated identities.

In my use, I try to separate identities, personas, and identifiers. Identifiers can label lots of stuff, including people. People can have multiple reputations, and I would call those personas. There is eventually only one person you can jail or issue a new passport to.

Adrian

On Sat, Dec 19, 2020 at 7:00 AM Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>> wrote:
I'm sorry to say that however interesting your elaboration is, I still have no clue what you refer to with "de-duplicated identities". I know that I'm slow in understanding others, and the more so if I really want to understand them. But alas, that's who I am... Could you make another attempt to enlighten me? Rieks

From: Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>
Sent: zaterdag 19 december 2020 09:52
To: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>>
Cc: W3C Credentials CG (Public List) <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: looking for a specific use-case

We need auditors or notaries with strictly limited knowledge _in almost every authorization_ .

Look at the recent news about widespread hacking / spying on non-classified government and large corporate networks https://www.nytimes.com/2020/12/19/us/pompeo-says-russia-was-behind-cyberattack-on-us.html or the solution to bots getting your PS5 before xmas https://games.slashdot.org/story/20/12/17/1852210/cant-get-a-playstation-5-meet-the-grinch-bots-snapping-up-the-holidays-hottest-gift


Speaking in my role as invited expert, I'm afraid our rush to privacy (SSI purity, don't phone home) in authentication without an equally thoughtful model for authorization and audit will male privacy worse by creating a false dichotomy with security. I see this risk throughout our work from VCs, to DIDs, to Confidential Storage and Interoperability. Everywhere I attend I am told we must do the simple thing first and layer authorization and audit later. I'm not sure that's going to work in terms of either privacy or adoption.

The alternative is to tackle zero-trust architecture right now while avoiding compromise in our self-sovereign principles. These should (must) not be competing priorities. I can also see the argument against my proposal, which is that we will be limiting the generativity of our SSI work and maybe shutting out some interesting and useful participants. I don't know how to reach this balance without having the discussion about authorization and audit sooner rather than later.

Adrian


On Sat, Dec 19, 2020 at 3:05 AM Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>> wrote:
Just to be sure I understand what you mean to say with "This is the reason for de-duplicated identities and notaries in the real world": In the example, we have "data that identifies the dependent", which obviously identifies the dependent in the context of the issuer that created the credential. The problem however is that it may not do so in the context of the verifier. In my vocabulary, 'de-duplication<https://en.wikipedia.org/wiki/Data_deduplication>' is the removal of copies of identical data, and I do not see how that fits here. Can you enlighten me? Rieks

From: Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>
Sent: woensdag 16 december 2020 13:35
To: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>>
Cc: W3C Credentials CG (Public List) <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: looking for a specific use-case

Yes, that makes perfect sense. This is the reason for de-duplicated identities and notaries in the real world.

I wrote some of this up as the Zener Diode in https://github.com/w3c/did-use-cases/issues/102#issuecomment-703943437


I've also heard an aspect of this described as 'sharing of liability' to certificate authorities where the CA is paid to isolate the issuer and/or the verifier from some liability.

Whether you call it a notary or a CA the common thing is that:
- they are bonded or certified as fiduciaries of the jurisdiction (typically the gov, but could be private)
- they verify a de-duplicated identity for the subject
- they keep a log that can be accessed at some significant cost if needed

I worry that our SSI use cases tend to be simplistic and artificial by not including audit, authorization, revocation, and mediating service providers as primary concerns. As an engineer I appreciate the desire of engineers to "layer" things and to model simple issuer, holder, verifier, registry relationships. As a privacy engineer with deep regulatory experience, I feel this is overly simplistic and will harm the adoption of our hard work.

Adrian

On Wed, Dec 16, 2020 at 3:48 AM Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>> wrote:
Thanks, Adrian, for your example. Let me summarize to see if I get the details:
You have been appointed a guardianship (over some other person - the dependent) by the state, that issued a credential to certify that relationship.
The credential contains data that identifies you, data that identifies the dependent.
It may also contain the (financial) rights/duties that go with this relationship, but such rights/duties may also be implicit (e.g. the law specifies them).
We have an SP that knows the dependent, and has some bad experiences with him/her.
-- now comes the part on which I like to focus: --
Then, the SP receives a request to provide some service, and it needs to know for/to whom to provide the service.
In normal circumstances, a service would be provided for/to the requester, causing the SP to authenticate the requester so that it can find the requester's account, ,and be done with it.
In guardianship circumstances, the requester can present a guardianship credential that allows the SP to authenticate you (and find your account) AND establish that you act as the guardian in a guardianship relationship (with some dependent).

I guess the issue I try to identify (before making attempts to solve it) is what the SP would need to be in the guardianship credential that would allow it to find the account of the dependent if that were to exist. The problem here is that the issuer of the guardianship credential may put data in the credential to identify the dependent that makes sense to the issuer, but it may not necessarily make sense to arbitrary SPs.

Does that make sense?
Rieks

From: Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>
Sent: dinsdag 15 december 2020 17:27
To: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>>
Cc: W3C Credentials CG (Public List) <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: looking for a specific use-case

Legal guardian accessing financial info at Schwab (as SP)

On Tue, Dec 15, 2020 at 11:16 AM Joosten, H.J.M. (Rieks) <mailto:rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>> wrote:
I'm looking for a use-case, which I think requires:
• that is realistic;
Common and I have first-hand experience as the guardian

• that involves (at least) two people, as e.g. in a marriage, a guardianship or otherwise, and some service provider (SP);
State-certified guardianship

• where SP has no earlier knowledge of any of these two people (he doesn't know who these people are);
The SP has a prior relationship with a money manager service but a tenuous relationship with the subject and no relationship with the (new) guardian.

• where SP can obtain credentials from only one of these persons (the other is somehow incapable of presenting credentials);
The guardian can provide a notarized document if necessary.

• where SP is requested to make a decision (e.g. to provide a service);
Access credentials to the guardian

• where SP needs to authenticate *both* persons in order to make that decision.
This is unclear. It sounds like you're looking for a new SP account like KYC but that does not involve a second party. If there is a prior account relationship with the SP then there is implicitly a link back to the account data subject.

Adrian

Any suggestions?
Rieks

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.