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> 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>
> *Sent:* maandag 21 december 2020 15:10
> *To:* Joosten, H.J.M. (Rieks) <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> 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>
> *Sent:* zaterdag 19 december 2020 13:44
> *To:* Joosten, H.J.M. (Rieks) <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> 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>
> *Sent:* zaterdag 19 december 2020 09:52
> *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
>
>
>
> 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> 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>
> *Sent:* woensdag 16 december 2020 13:35
> *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
>
>
>
> 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> 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>
> Sent: dinsdag 15 december 2020 17:27
> 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
>
> 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> 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.
>
>