[OpenID-Specs-eKYC-IDA] Data Rights Protocol and eKYC

Mon Oct 11 23:37:22 UTC 2021

Thank you for the warm welcome, Gail and Mark. I'd be happy to join an
upcoming working group meeting to introduce myself and share a bit more
about what we're working on with the Data Rights Protocol. Would it be
possible to join the October 20th working group session?

I'm also open to having a brief 'side huddle' this week to make sure we
make the most effective use of the WG's time by agreeing on an
agenda/structure.

John

On Tue, Oct 5, 2021 at 3:13 AM Gail Hodges via Openid-specs-ekyc-ida <
openid-specs-ekyc-ida at lists.openid.net> wrote:

> + Mike L
>
>
>
> Hi John
>
>
>
> As Exec Director of the OIDF I’d just like to echo Mark’s comments – we
> warmly welcome exploration of OIDF standards to support entities seeking to
> comply with their CCPA/GDPR obligations.
>
>
>
> eKYC & IDA WG is indeed the best place to start the conversation, and
> discuss the use case in more detail. Time is weekly 8am PT/ 11am ET every
> Wednesday, hosted by Mark Haine. Attendees can also speak to the related
> standards, OpenID Connect & FAPI. The only requirement to participate in
> the WG conversation is to sign the IPR contribution agreement, since we are
> an open standards body. Since you are working on open standards as well
> that should not be any impediment. https://openid.net/wg/ekyc-ida/
>
>
>
> As a personal note, I have thought that the standards underway in OIDF
> (and separately those on mobile driving licenses in ISO18013-5) could help
> achieve compliance & conformance to CCPA & GDPR, and partnership with your
> group could help accelerate that timetable.
>
>
>
> Just let me know if you prefer a “side huddle” pre or post the eKYC WG
> conversation, I’m happy to help organize.
>
>
>
> Gail
>
>
>
> *From: *Openid-specs-ekyc-ida <
> openid-specs-ekyc-ida-bounces at lists.openid.net> on behalf of Mark Haine
> via Openid-specs-ekyc-ida <openid-specs-ekyc-ida at lists.openid.net>
> *Reply-To: *OpenID eKYC Identity Assurance Working Group <
> openid-specs-ekyc-ida at lists.openid.net>
> *Date: *Monday, October 4, 2021 at 2:39 AM
> *To: *Dazza Greenwood <dazza.greenwood.consultant at consumer.org>, Ryan Rix
> <ryan.rix.consultant at consumer.org>, Marc Llahona <marc at datagrail.io>,
> John Gronberg <gronberg at datagrail.io>
> *Cc: *Mark Haine <mark at considrd.consulting>, OpenID eKYC Identity
> Assurance Working Group <openid-specs-ekyc-ida at lists.openid.net>
> *Subject: *Re: [OpenID-Specs-eKYC-IDA] Data Rights Protocol and eKYC
>
>
>
> Hi John,
>
>
>
> Thanks so much for your mail and for bring this topic to the group.  In
> the first instance it would be great if you or colleagues could attend one
> of our working group meetings and introduce yourselves, you would be very
> welcome.   We are active in finding real world use cases to test the base
> hypothesis of our work and it sounds like this is one that we haven’t
> imagined as yet.
>
> I personally find this use case really interesting and have done a little
> thinking around something that might be quite similar and looks to address
> the lack of a standardised interface for Data Subject Requests although I
> hadn’t got to the point of specifying an interface.
>
>
>
> With regards to your questions I shall have a go but these are not
> authoritative answers from the WG!  I also hope that I have understood your
> questions well enough.
>
>
>
> 1 – trust model – The OIDF focusses on tools not rules and as such we do
> not attend to the trust model side of things as that is in the policy
> domain rather than the technology domain.  We have a partner organisation
> called the Open Identity Exchange that has been working on a definition of
> the component parts of a trust framework that you may find quite useful.
>
>
>
> 2 – Workflow for claims – I am not sure I understand this question
> properly but we do have an open issue that relates to how the spec might be
> able to handle request for claims that need to be established through a
> more time consuming process than claims that are readily available to the
> PIP
>
>
>
> 3 – API Authorisation – I expect so
>
>
>
> 4 – other concerns – Have you looked at the security profile work coming
> out of the FAPI working group?  We would encourage use of FAPI to mitigate
> security risks when using OIDC for IDA with any sensitive information or
> PII.
>
>
>
> Mark Haine
>
>
>
> OpenID Foundation eKYC & IDA Working Group Co-chair
>
>
>
> +44 (0) 777 555 0344 | mark at considrd.consulting | considrd.consulting
> <https://www.considrd.consulting/> | 30 The Grange, Irvine.  KA11 2EU
>
> [image: considrd.consulting logo][image: OpenID Logo]
> <https://www.considrd.consulting/>[image: signature_900739338]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From: *Openid-specs-ekyc-ida <
> openid-specs-ekyc-ida-bounces at lists.openid.net> on behalf of John
> Gronberg via Openid-specs-ekyc-ida <openid-specs-ekyc-ida at lists.openid.net
> >
> *Reply to: *OpenID eKYC Identity Assurance Working Group <
> openid-specs-ekyc-ida at lists.openid.net>
> *Date: *Friday, 1 October 2021 at 19:28
> *To: *"openid-specs-ekyc-ida at lists.openid.net" <
> openid-specs-ekyc-ida at lists.openid.net>, Dazza Greenwood <
> dazza.greenwood.consultant at consumer.org>, Ryan Rix <
> ryan.rix.consultant at consumer.org>, Marc Llahona <marc at datagrail.io>
> *Cc: *John Gronberg <gronberg at datagrail.io>
> *Subject: *[OpenID-Specs-eKYC-IDA] Data Rights Protocol and eKYC
>
>
>
> Hello eKYC WG,
>
>
>
> I'm part of a consortium of privacy infrastructure and technology
> businesses working to create an open standard for Data Subject Rights (DSR)
> Requests for businesses under the jurisdiction of the CCPA. You can read a
> little bit more about the protocol here: http://datarightsprotocol.org
>
>
>
> *"This specification defines a web protocol encoding a set of standardized
> request/response data flows such that End-Users can exercise Personal Data
> Rights provided under regulations like the California Consumer Privacy Act,
> General Data Protection Regulation, and other regulatory or voluntary
> bases, and receive affirmative responses in standardized formats.*
>
>
>
> *We aim to make the data rights protocol integrable with an ecosystem of
> data rights middlewares, agent services, automation tool kits, and
> privacy-respecting businesses which empower and build trust with consumers
> while driving the cost of compliance towards zero."*
>
>
>
> We believe that the eKYC extension to OIDC would be a good fit for our use
> case. I will lay out the scenario below
>
>
>
> These are the relevant entities:
>
>    - a *data subject*: A natural person about whom a controller holds
>    personal data and who can be identified, directly or indirectly, by
>    reference to that personal data
>    - an *authorized agent*: A third party designated by a Consumer to
>    perform Data Subject Requests on their behalf. This would be like a user
>    agent/app.
>    - a *Privacy Infrastructure Provider (PIP)*: a technology solution
>    that can orchestrate a DSR request for a business.
>    - *a covered business*: A natural or legal person, public authority,
>    agency or other body which, alone or jointly with others, determines the
>    purposes and means of the processing of personal data and is subject to the
>    CCPA.
>
> A data subject will initiate one or more data subject requests through an
> authorized agent. The authorized agent will create these requests with one
> or more covered businesses. The covered business will have certain
> requirements in place for establishing the identity of the data subject.
> Once the requirements are met, the businesses will process the rights
> requests (for erasure, access, etc) based on their internal processes, or
> the PIP will do so on behalf of the covered business. Upon completion of
> the internal processes, the results of the rights request will be returned
> to the authorized agent for delivery to the data subject.
>
>
>
> We're trying to answer the following questions:
>
>    1. Identity claims could be supplied by the authorized agent or the
>    PIP/covered business. What is the proper trust model and how can we
>    establish confidence in the claims?
>    2. The PIP/covered business may need to get identity claims that the
>    authorized agent does not yet have (for instance, if the covered business
>    is an ecommerce company it may want to know the date of the last order
>    placed by the data subject). What is the right model for us to establish
>    such claims?
>    3. Presumably, for the API authorization that would go along with the
>    identity claims, we would be able to use the standard OIDC flow with the
>    PIP/covered business acting as the authorization server and the authorized
>    agent acting as a user agent, correct?
>    4. Do you have any concerns or other questions as we figure out how to
>    meet our DSR use cases with OIDC?
>
> We've put together a few explanatory diagrams in this document
> <https://github.com/consumer-reports-digital-lab/data-rights-protocol/blob/main/files/eKYC-WG-feedback.pdf>
> for further explanation.
>
>
>
> We're looking forward to your input! I will be unavailable via email for
> the next week, but will respond to comments upon my return.
>
>
>
> Cheers,
>
> John
>
>
> --
> Openid-specs-ekyc-ida mailing list
> Openid-specs-ekyc-ida at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20211011/e750bc1f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 22134 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20211011/e750bc1f/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 8441 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20211011/e750bc1f/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 5569 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20211011/e750bc1f/attachment-0005.png>