<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
To have transaction specific parameters included in the URN makes sense to me indeed.
<div class="">By the way, I don’t really like the schema i proposed for the ‘lawful_purpose’, so this is an improved version of that:</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">{</div>
<div class="">  "userinfo":{</div>
<div class="">     "verified_claims":{</div>
<div class="">        "verification": {</div>
<div class="">           "trust_framework": "ial_example_gold"</div>
<div class=""><br class="">
</div>
<div class="">        },</div>
<div class="">        "claims":{</div>
<div class="">           "given_name":"Max",</div>
<div class="">           "family_name": "Meier",</div>
<div class="">           "birthdate": "0000-03-22"</div>
<div class="">        }</div>
<div class="">     }</div>
<div class="">     "lawful_purposes" [</div>
<div class="">        {</div>
<div class="">           "claim": "given_name",</div>
<div class="">           "purpose": "To make communication look more personal"</div>
<div class="">        },</div>
<div class="">        {</div>
<div class="">           "claim": "birthdate",</div>
<div class="">           "purpose": "To validate the user is an adult and parental responsibilities are not applicable"</div>
<div class="">        },</div>
<div class="">        {</div>
<div class="">            "claim": "birthdate",</div>
<div class="">           "purpose": "The user has reached the age of majority"</div>
<div class="">        },</div>
<div class="">        {</div>
<div class="">            "claim": "birthdate",</div>
<div class="">            "purpose_urn": "urn:example:some-purpose-id?=contract=XYZ&insurance=ABC"</div>
<div class="">        }</div>
<div class="">     ]</div>
<div class="">  }</div>
<div class="">}</div>
<div class=""><br class="">
</div>
<div class="">This is a better json structure and allows more naturally for schema extensions for lawfull purposes.</div>
<div class="">When the legal ground is consent, the fields as defined in <a href="file:///Users/jaap/Downloads/consent-receipt-specification-v1-1-0.pdf" class="">file:///Users/jaap/Downloads/consent-receipt-specification-v1-1-0.pdf</a> can be considered for
 defining the schema. But I wouldn’t expect the full details to be part of the Openid-specs-ekyc-ida spec.</div>
<div class=""><br class="">
</div>
<div class="">I think it’s better to have separate fields for textual purposes versus URN-purposes.</div>
<div class="">The urn could (as Joseph/Torsten suggested) include q-component.</div>
<div class=""><br class="">
</div>
<div class="">Kind regards,</div>
<div class=""><br class="">
</div>
<div class="">Jaap</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 25 May 2020, at 12:10, <a href="mailto:openid-specs-ekyc-ida-request@lists.openid.net" class="">
openid-specs-ekyc-ida-request@lists.openid.net</a> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Send Openid-specs-ekyc-ida mailing list submissions to<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span><a href="mailto:openid-specs-ekyc-ida@lists.openid.net" class="">openid-specs-ekyc-ida@lists.openid.net</a><br class="">
<br class="">
To subscribe or unsubscribe via the World Wide Web, visit<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida<br class="">
or, via email, send a message with subject or body 'help' to<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>openid-specs-ekyc-ida-request@lists.openid.net<br class="">
<br class="">
You can reach the person managing the list at<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>openid-specs-ekyc-ida-owner@lists.openid.net<br class="">
<br class="">
When replying, please edit your Subject line so it is more specific<br class="">
than "Re: Contents of Openid-specs-ekyc-ida digest..."<br class="">
<br class="">
<br class="">
Today's Topics:<br class="">
<br class="">
  1. Re: Usage of scopes and purposes when requesting verified<br class="">
     claims (Torsten Lodderstedt)<br class="">
  2. Re: Usage of scopes and purposes when requesting verified<br class="">
     claims (Joseph Heenan)<br class="">
<br class="">
<br class="">
----------------------------------------------------------------------<br class="">
<br class="">
Message: 1<br class="">
Date: Sun, 24 May 2020 17:02:31 +0200<br class="">
From: Torsten Lodderstedt <torsten@lodderstedt.net><br class="">
To: Vladimir Dzhuvinov <vladimir@connect2id.com><br class="">
Cc: OpenID eKYC Identity Assurance Working Group<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span><openid-specs-ekyc-ida@lists.openid.net>,  Jaap Francke<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span><jaap.francke@iwelcome.com><br class="">
Subject: Re: [OpenID-Specs-eKYC-IDA] Usage of scopes and purposes when<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>requesting verified claims<br class="">
Message-ID: <F464DE66-8D31-4AAB-9BB8-FEBC39B9CB17@lodderstedt.net><br class="">
Content-Type: text/plain;<span class="Apple-tab-span" style="white-space:pre"> </span>
charset=utf-8<br class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On 24. May 2020, at 08:50, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:<br class="">
<br class="">
<br class="">
<br class="">
On 23/05/2020 14:25, Torsten Lodderstedt wrote:<br class="">
<blockquote type="cite" class=""><br class="">
<blockquote type="cite" class="">On 14. May 2020, at 09:51, Vladimir Dzhuvinov <vladimir@connect2id.com><br class="">
wrote:<br class="">
<br class="">
Thanks Jaap for doing this work and the proposals.<br class="">
<br class="">
I find the purpose URNs highly useful. This makes it possible for providers or an ecosystem to have a well defined common set of purposes, which will also act as sort of guideline for client applications on what grounds verified claims can be requested. Consent
 for users can also be made more consistent and informative for users.<br class="">
<br class="">
</blockquote>
I like the URN idea as well. However, I have already seen instances in the wild where the purpose text is dynamically created for a certain transaction, e.g. ?identification data to sign contract XYZ for insurance ABC?. I therefore think there also needs to
 be a way to pass transaction specific purpose values. <br class="">
</blockquote>
URN with query parameters to pass TX specific values?<br class="">
<br class="">
https://tools.ietf.org/html/rfc8141#section-2.3.2<br class="">
<br class="">
urn:example:some-purpose-id?=contract=XYZ&insurance=ABC<br class="">
</blockquote>
<br class="">
You mean in the sense of the URN determines a template and the parameters are resolved at run time within this template?<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
<blockquote type="cite" class="">Vladimir<br class="">
<br class="">
On 11/05/2020 17:38, Jaap Francke via Openid-specs-ekyc-ida wrote:<br class="">
<br class="">
<blockquote type="cite" class="">Hi Torsten, Achim and others<br class="">
<br class="">
Resuming our previous email conversation?.<br class="">
<br class="">
On the topic of RP-specific scopes. Yes I?ve seen this in practice, maybe not in eIDAS context, but in general with OAuth, we have seen various situations where custom claims are requested via custom scopes, which may be RP specific. I think Achim?s proposal
 addresses my initial remark.<br class="">
<br class="">
On the the topic of consent and legal aspects. I started drafting proposed texts and changes as you suggested and came to realize that in my view a claim may be requested for one or multiple purposes. GDPR mandates that legal grounds for processing need to
 be addressed at a granular level. Processing purposes should not be bundled. <br class="">
The point from my previous email was to not make an assumption on how legal aspects are addressed in the protocol itself. So to facilitate both of ?my? requirements, I think the protocol should maybe allow for the following:<br class="">
- RP can indicate for what purpose(s) it is requesting a (verified) claim<br class="">
- The OP can indicate which purpose(s) it knows that are somehow ?legally covered? (which applies both to regular and verified claims)<br class="">
- Instead of a processing purpose being a descriptive string, it could be a urn.<br class="">
In response to Achim?s remark, I do believe that data protection details should be covered by a specification. The challenge is to not do so in a flexible way. Another option could be to take the whole concept of ?purpose? out of the spec, since it is not by
 definition related to the concept of VERIFIED claims.<br class="">
<br class="">
So as a reult of these ideas of mine, I am proposing enhancements of the specifications as per ?below'. I hope it makes sense (and also hope it is well formulated, not being a native speaker sometimes makes it a bit difficult for me to express myself clearly).<br class="">
<br class="">
Kind regards,<br class="">
<br class="">
Jaap Francke<br class="">
<br class="">
<br class="">
-------<br class="">
<br class="">
SECTION 4.4 Lawful purposes Element<br class="">
This specification defines a generic mechanism to add purposes to claims. Since both verified cliams and regular claims transfer personal data the purposes can be indicated for any of such claims.
<br class="">
<br class="">
The normative definition is given in the following.?<br class="">
<br class="">
lawful_purposes: Object or array containing one or more purposes for processing of a user's data by RP and for which the OP knows a lawful basis exists. A purpose may be a descriptive sentence or may be a urn for a previously established processing purpose.<br class="">
<br class="">
Note: An OP may decide to provide a claim without knowledge of a lawfull basis for the specific user. The protocol does not mandate a specific devision of responsibilities over the OP and RP.<br class="">
<br class="">
Note: User?s consent is a lawful basis. Another example may be a legal obligation for the RP.<br class="">
<br class="">
Note: An RP and a OP may agree on a set of data processing purposes and refer to those using a urn. Part of tis agreement may be a their lawful bases, user?s consent on Privacy Policies and how to obtain consent, etc. At the urn, more generic details about
 the lawful basis may be made available, such as an indicator for the Data Controller (legally responsible entity), etc.<br class="">
<br class="">
Example:<br class="">
<br class="">
{<br class="">
  "userinfo":{<br class="">
     "verified_claims":{<br class="">
        "verification": {<br class="">
           "trust_framework": ?<br class="">
ial_example_gold"<br class="">
<br class="">
        },<br class="">
        "claims":{<br class="">
           "given_name":"Max",<br class="">
           "family_name": "Meier",<br class="">
           "birthdate": "0000-03-22"<br class="">
        }<br class="">
     }<br class="">
     ?lawful_purposes" : {<br class="">
        "given_name" : {<br class="">
           "To make communication look more personal"<br class="">
        }<br class="">
        "birthdate" : {<br class="">
           "To validate the user is an adult and parental responsibilities are not applicable",<br class="">
           ?The user has reached the age of majority"<br class="">
        }<br class="">
     }<br class="">
  }<br class="">
}<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
SECTION 5.1.<br class="">
<br class="">
This specification introduces the additional field purposes to allow an RP to state the purpose(s) for the transfer of a certain End-User Claim it is asking for. The field purposes can be a member value of each individually requested Claim. A Claim can have
 more than one associated purpose.<br class="">
<br class="">
purposes: OPTIONAL. An array of string describing the purposes for obtaining a certain End-User Claim from the OP.
<br class="">
<br class="">
Each purpose MUST NOT be shorter than 3 characters or longer than 300 characters. If this rule is violated, the authentication request MUST fail and the OP return an error invalid_request to the RP. A purpose may be a descriptive sentence or may be a urn for
 a previously established processing purpose.<br class="">
<br class="">
The OP MAY display one or more of the purposes on a user screen(s) in order to inform the user about the designated use of the data to be transferred. The lawful basis for the transfer of the personal data may differ for different implementations and the legal
 aspects are out of scope of this specification. A specific purpose may or may not require that the user?s consent is obtained by either OP or RP. If the parameter purpose is not present in the request, the OP MAY display a value that was pre-configured for
 the respective RP. For details on UI localization, see Section 8.<br class="">
<br class="">
<br class="">
Example:<br class="">
<br class="">
{<br class="">
  "userinfo":{<br class="">
     "verified_claims":{<br class="">
        "verification": {<br class="">
           "trust_framework": null<br class="">
        },<br class="">
        "claims":{<br class="">
           "given_name":{<br class="">
              "essential":true,<br class="">
              "purposes": [<br class="">
                 "To make communication look more personal"<br class="">
              ]<br class="">
           },<br class="">
           "family_name":{<br class="">
              "essential":true<br class="">
           },<br class="">
           "birthdate":{<br class="">
              "purposes": [<br class="">
                 "To send you best wishes on your birthday?,<br class="">
                 "To validate the user is an adult and parental responsibilities are not applicable"<br class="">
           }<br class="">
        }<br class="">
     }<br class="">
  }<br class="">
}<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On 1 May 2020, at 18:25, Torsten Lodderstedt <torsten@lodderstedt.net><br class="">
wrote:<br class="">
<br class="">
Hi Jaap,<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On 1. May 2020, at 15:23, Jaap Francke <jaap.francke@iwelcome.com><br class="">
wrote:<br class="">
<br class="">
Hi Torsten,<br class="">
<br class="">
Thanks for your reply. My comments are also inline.<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html<br class="">
<br class="">
<br class="">
The "OIDC for identity Assurance? specs introduce a number of claims, in addition to the ones specificied by OIDC core.<br class="">
In OIDC Core, there are 2 mechanisms to request claims:<br class="">
- one is by usage of OAuth-scopes, (section 5.4 of Core spec)<br class="">
- one by usage of the ?claims? parameter in the request. (section 5.5 of Core spec)<br class="">
Section 5 of the OIDC?identity-assurance specs indicate the usage of the claims pararameter. This may suggest it?s the only mechanism to be used in the context of Identity Assurance.<br class="">
My view is that also the ?scope? mechanism should be supported and may even be preferred for certain use cases.<br class="">
Please enhance the specification to be more explicit about usage of scopes as a means to request verified claims.<br class="">
<br class="">
Usage of ?scope? to request verified claims makes sense to me because in a typical ?identity landscape? the requested claims do not vary on a request-by-request basis, but instead are a reflection of an RP?s functionality which can be rather static. By pre-defining/configuring
 scopes at the OP (potentially in terms of ?essential?, ?trust_framework?, etc..), the scope is essentially a profile of the claim request. This would not only simplify the protocol implementation both at the RP and OP side, but it would also make it easier
 for the OP to make the authorisation decision whether or not the RP will be granted the requested verified claims. 'It is at the discretion of the OP to decide whether the requested verification data is provided to the RP.? Making this decision is much easier
 when a request includes a scope as a reference to a predefined profile of requested end-user claims and associated verification data. My suggestion is to consider including such a mechanism in t<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
he specifications.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
</blockquote>
What do you have in mind? I agree a certain RP or deployment could define scope values as short cut to request certain verified claims. However, the number and value range of verification elements + the number of end user claims creates is so big I cannot envision
 how the spec could define concrete scope values.<br class="">
<br class="">
</blockquote>
Yes, so what i had in mind is that the spec would acknowledge the practice of defining a ?custom' scope value as shortcut to request certain claims. The current spec only mentions the ?claims? request parameter as mechanism to request claims, which I see as
 somewhat ambigous The spec could mention both mechanisms as valid options and leave it to the the implementor to make a choice which mechanism is more appropriate.
<br class="">
My preference is the ?scope? approach, since it fits into what i see as a typical situation where the interaction between RP and OP has a more ?static? nature.
<br class="">
I could imagine the spec even stating perceived pros&cons of both approaches. Claims approach gives a lot of flexibility to vary on a request-by-request basis. The scope approach is easier in situations where there is a ?static? interaction between OP and RP;
 i.e. an RP may always want to receive the same set of claims, for the same data processing and purpose, etc.<br class="">
<br class="">
</blockquote>
I assume the interaction can be static for a certain RP with a certain OP. This would call for RP-specific scope values. Have you ever seen this in practice? I haven?t.
<br class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Additionally, the spec no longer defines values for trust frameworks, verification methods and evidence, i.e. there are unknown values from a spec perspective.<br class="">
<br class="">
<blockquote type="cite" class="">My second observation is about the optional ?purpose? parameter in a claims request. The specs state that the OP MUST display this purpose in the respective user consent screen(s) in order to inform the user about the designated
 use of the data to be transferred or the authorization to be approved. If the parameter purpose is not present in the request, the OP MAY display a value that was pre-configured for the respective RP.?
<br class="">
This part of the specification assumes or seems to imply that the user gets a consent screen every time that verified data is requested. I think that this is not realistic:<br class="">
- it is common practice that certain consents are included in a Privacy Policy (PP) and/or Terms of Service (ToS). The user gives his consent once and the consent is persisted at the OP for future purposes.<br class="">
<br class="">
</blockquote>
Are you referring to ToS/PP of the RP or the OP?<br class="">
<br class="">
</blockquote>
Good question. I think it could be either one or maybe even both. My understanding of the European GDPR is that the OP may need the user?s consent to provide data to the RP and the RP needs a legal ground to collect a person?s data. This is assuming that RP
 and OP are different legal entities / Data Controllers. Different scenario?s can also be possible where OP and/or RP (from a legal perspecrive) could be Data Controller or Data Processor. Moreover, i think legal entities can even delegate the responsibility
 to get a user?s consent (if consent is the legal ground that is applicable)<br class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">- if not in PP or ToS, a consent screen may be presented only ?once? and the user?s consent is taken to be valid for the next 6 months (as an example)<br class="">
- in some situations there are other legal grounds/reasons/purposes to request the claims and verification data. Besides ?consent?, the European GDPR indicates other legal grounds (contract, vital interest, legal obligation, ..). When an RP asks for a verified
 claim, it may do so based on a legal obligation and the user?s consent would not be needed.<br class="">
- Privacy regulations aim at situations where personal data is exchanged between legal entities (data controllers, data processors). From an IT perspective, the OP and the RP may be operated by the same entity (for example an Insurance company as                     data
 controller that is both the data controller for the OP and various RPs) so consent would not apply at the moment of requesting the claim. The consent should already have been given at the moment the personal data was provided to the OP.<br class="">
My proposal would be that the ?purpose? could be a string (as per current specification) or a reference to a ?purpose? that has already been established somewhere. This approach makes it easier for the OP to make the decision to provide the requested data or
 not.<br class="">
<br class="">
</blockquote>
I agree the text is too strong. The purpose should be used to further inform the user in case a user consent screen is required. I will try to change the text accordingly.<br class="">
<br class="">
</blockquote>
Extending my previous replies, my suggestion would be that the eKYC standard would not ?enforce? or assume whatever particular legal set-up of responsibilities, but instead facilitate any legal context and/or interpretation.<br class="">
I think the way to do so would be to include the possibility to include one or more references to types of data processing (?purposes?) that should somehow be legally covered.<br class="">
How this ?legal cover? is arranged for may vary per implementation:<br class="">
- Is the OP Data Controller or Data Processer? Is the RP Data Controller or Data Processer?<br class="">
- Does the intended data processing require the user?s consent or does one of the other legal grounds apply?<br class="">
- Did RP and OP agree on some delegation about getting the user?s consent (if needed)?<br class="">
In this way the protocol can facilitate any set-up in a transparant way, without making assumptions on legal reponsibilities at either OP and/or RP.<br class="">
<br class="">
</blockquote>
What does this mean to protocol constructs? Can you please suggest concrete changes/text?<br class="">
<br class="">
<br class="">
<blockquote type="cite" class=""><br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Furthermore, it could be considered to extend the list of verification methods with the ones defined by NISTIR 8112.<br class="">
<br class="">
</blockquote>
You mean ?Document Verification?, ?Record Verification?, ?Document Verification with Record Verification?, ?Proof of Possession?, ?Probabilistic Verification?, ?Not Verified?? We could add this to our Wiki. May I ask you to add the values?<br class="">
<br class="">
</blockquote>
Yes that?s what I meant. I need to familiarize with the wiki.<br class="">
<br class="">
</blockquote>
You may find the existing definitions at https://bitbucket.org/openid/ekyc-ida/wiki/identifiers<br class="">
.<br class="">
<br class="">
Let me know if you want to contribute changes, the I would give you the respective permissions.
<br class="">
<br class="">
best regards,<br class="">
Torsten. <br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">-- <br class="">
Openid-specs-ekyc-ida mailing list<br class="">
<br class="">
Openid-specs-ekyc-ida@lists.openid.net<br class="">
http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
-- <br class="">
Vladimir Dzhuvinov<br class="">
<br class="">
</blockquote>
<br class="">
<br class="">
<br class="">
------------------------------<br class="">
<br class="">
Message: 2<br class="">
Date: Mon, 25 May 2020 11:10:48 +0100<br class="">
From: Joseph Heenan <joseph@authlete.com><br class="">
To: OpenID eKYC Identity Assurance Working Group<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span><openid-specs-ekyc-ida@lists.openid.net><br class="">
Cc: Achim Schlosser <achim.schlosser@enid.eu>, Torsten Lodderstedt<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span><torsten@lodderstedt.net>, Jaap Francke <jaap.francke@iwelcome.com><br class="">
Subject: Re: [OpenID-Specs-eKYC-IDA] Usage of scopes and purposes when<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>requesting verified claims<br class="">
Message-ID: <EF124CD5-82C1-418A-BFA1-2FB0C9C20245@authlete.com><br class="">
Content-Type: text/plain; charset="utf-8"<br class="">
<br class="">
Hi all,<br class="">
<br class="">
I?m a little late into this conversation, but I?d like to share some recent experience.<br class="">
<br class="">
The use of the ?scope? shorthand in OpenID Connect Core is not quite as tightly defined as you might like - the spec:<br class="">
<br class="">
https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims <https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims><br class="">
<br class="">
says:<br class="">
<br class="">
<blockquote type="cite" class="">The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section?5.3.2, when a?response_type?value is used that results in an Access Token being issued.
 However, when no Access Token is issued (which is the case for the?response_type?value?id_token), the resulting Claims are returned in the ID Token. <https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse><br class="">
</blockquote>
<https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse><br class="">
This doesn?t go as far as saying ?the email MUST NOT be returned in the front channel id_token for response_type=code id_token? (there?s also language elsewhere that most people miss suggesting the email claim maybe shouldn?t be returned in the front channel
 if it would be available via a back channel method).<br class="">
<br class="">
For example, I recently discovered that several OPs, including at least one very large one, always return ?email? in all id_tokens (as well as the intended location in the userinfo response) when requested by scope=email. This is not disallowed by the Connect
 spec, but returning the more sensitive information involved in eKYCs responses in front channel id_tokens or in back channel id_tokens (that may be shared with third parties etc) would probably be unwise and/or not unexpected by the RP - could potentially
 lead to to PII being held in unexpected places or unintentionally shared.<br class="">
<br class="">
I?d perhaps suggest adding a privacy or security consideration along the lines that as a minimum any agreement to use scope shorthands (particularly when they?d apply across a whole ecosystem and hence RPs may not closely check exactly how each OP behaves)
 should make it clear which locations the resulting claims must/must not be returned in.<br class="">
<br class="">
Cheers,<br class="">
<br class="">
Joseph<br class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On 8 May 2020, at 08:22, Torsten Lodderstedt via Openid-specs-ekyc-ida <openid-specs-ekyc-ida@lists.openid.net> wrote:<br class="">
<br class="">
Hi Achim,<br class="">
<br class="">
sounds reasonable. I will create PRs.<br class="">
<br class="">
thanks,<br class="">
Torsten. <br class="">
<br class="">
<blockquote type="cite" class="">On 5. May 2020, at 11:08, Achim Schlosser <achim.schlosser@enid.eu> wrote:<br class="">
<br class="">
Hi all,<br class="">
<br class="">
<br class="">
Moving this out of in-line comments:<br class="">
<br class="">
Scope Usage: <br class="">
<br class="">
In general there is nothing in the spec that would prohibit RP and OP to agree on sets of claims/trust frameworks that they would expose via simple scope requests. I would suggest to add some general language around this and leave it there, scopes are by definition
 only shortcuts to claim requests.<br class="">
<br class="">
Proposal:<br class="">
<br class="">
5.x Requesting Verified Claims using Scope Values<br class="">
<br class="">
As defined in (REF 5.4 Core Spec https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims) scopes can be used to request that specific sets of information be made available as Claim Values. This specification defines no additional predefined scopes.
 OPs MAY define scope values to request verified claims. <br class="">
<br class="">
Purpose:<br class="">
<br class="">
As with similar topics I would strongly encourage to not venture into Data Protection details in any form with the specification, but rather soften the language and not go beyond what is already written in the core spec.
<br class="">
<br class="">
Core spec defines this - https://openid.net/specs/openid-connect-core-1_0.html#Consent - Just leave it with that. The usage of the word consent in the core spec is already problematic as it is now with GDPR in mind, so it can only get worse.<br class="">
<br class="">
Proposal:<br class="">
<br class="">
Remove any MUST language in relation to the purpose and also MAY language in case it relates to unilateral action of the OP.<br class="">
<br class="">
<br class="">
Best<br class="">
<br class="">
Achim <br class="">
<br class="">
?On 01.05.20, 18:26, "Openid-specs-ekyc-ida on behalf of Torsten Lodderstedt via Openid-specs-ekyc-ida" <openid-specs-ekyc-ida-bounces@lists.openid.net on behalf of openid-specs-ekyc-ida@lists.openid.net> wrote:<br class="">
<br class="">
 Hi Jaap,<br class="">
<br class="">
<blockquote type="cite" class="">On 1. May 2020, at 15:23, Jaap Francke <jaap.francke@iwelcome.com> wrote:<br class="">
<br class="">
Hi Torsten,<br class="">
<br class="">
Thanks for your reply. My comments are also inline.<br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html<br class="">
<br class="">
The "OIDC for identity Assurance? specs introduce a number of claims, in addition to the ones specificied by OIDC core.<br class="">
In OIDC Core, there are 2 mechanisms to request claims:<br class="">
- one is by usage of OAuth-scopes, (section 5.4 of Core spec)<br class="">
- one by usage of the ?claims? parameter in the request. (section 5.5 of Core spec)<br class="">
Section 5 of the OIDC?identity-assurance specs indicate the usage of the claims pararameter. This may suggest it?s the only mechanism to be used in the context of Identity Assurance.<br class="">
My view is that also the ?scope? mechanism should be supported and may even be preferred for certain use cases.<br class="">
Please enhance the specification to be more explicit about usage of scopes as a means to request verified claims.<br class="">
<br class="">
Usage of ?scope? to request verified claims makes sense to me because in a typical ?identity landscape? the requested claims do not vary on a request-by-request basis, but instead are a reflection of an RP?s functionality which can be rather static. By pre-defining/configuring
 scopes at the OP (potentially in terms of ?essential?, ?trust_framework?, etc..), the scope is essentially a profile of the claim request. This would not only simplify the protocol implementation both at the RP and OP side, but it would also make it easier
 for the OP to make the authorisation decision whether or not the RP will be granted the requested verified claims. 'It is at the discretion of the OP to decide whether the requested verification data is provided to the RP.? Making this decision is much easier
 when a request includes a scope as a reference to a predefined profile of requested end-user claims and associated verification data. My suggestion is to consider including such a mechanism in the
<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
specifications.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
What do you have in mind? I agree a certain RP or deployment could define scope values as short cut to request certain verified claims. However, the number and value range of verification elements + the number of end user claims creates is so big I cannot envision
 how the spec could define concrete scope values.<br class="">
</blockquote>
<br class="">
Yes, so what i had in mind is that the spec would acknowledge the practice of defining a ?custom' scope value as shortcut to request certain claims. The current spec only mentions the ?claims? request parameter as mechanism to request claims, which I see as
 somewhat ambigous The spec could mention both mechanisms as valid options and leave it to the the implementor to make a choice which mechanism is more appropriate.
<br class="">
My preference is the ?scope? approach, since it fits into what i see as a typical situation where the interaction between RP and OP has a more ?static? nature.
<br class="">
I could imagine the spec even stating perceived pros&cons of both approaches. Claims approach gives a lot of flexibility to vary on a request-by-request basis. The scope approach is easier in situations where there is a ?static? interaction between OP and RP;
 i.e. an RP may always want to receive the same set of claims, for the same data processing and purpose, etc.<br class="">
</blockquote>
<br class="">
 I assume the interaction can be static for a certain RP with a certain OP. This would call for RP-specific scope values. Have you ever seen this in practice? I haven?t.
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class=""><br class="">
<blockquote type="cite" class="">Additionally, the spec no longer defines values for trust frameworks, verification methods and evidence, i.e. there are unknown values from a spec perspective.<br class="">
<blockquote type="cite" class=""><br class="">
My second observation is about the optional ?purpose? parameter in a claims request. The specs state that the OP MUST display this purpose in the respective user consent screen(s) in order to inform the user about the designated use of the data to be transferred
 or the authorization to be approved. If the parameter purpose is not present in the request, the OP MAY display a value that was pre-configured for the respective RP.?
<br class="">
This part of the specification assumes or seems to imply that the user gets a consent screen every time that verified data is requested. I think that this is not realistic:<br class="">
- it is common practice that certain consents are included in a Privacy Policy (PP) and/or Terms of Service (ToS). The user gives his consent once and the consent is persisted at the OP for future purposes.<br class="">
</blockquote>
<br class="">
Are you referring to ToS/PP of the RP or the OP?<br class="">
</blockquote>
<br class="">
Good question. I think it could be either one or maybe even both. My understanding of the European GDPR is that the OP may need the user?s consent to provide data to the RP and the RP needs a legal ground to collect a person?s data. This is assuming that RP
 and OP are different legal entities / Data Controllers. Different scenario?s can also be possible where OP and/or RP (from a legal perspecrive) could be Data Controller or Data Processor. Moreover, i think legal entities can even delegate the responsibility
 to get a user?s consent (if consent is the legal ground that is applicable)<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">- if not in PP or ToS, a consent screen may be presented only ?once? and the user?s consent is taken to be valid for the next 6 months (as an example)<br class="">
- in some situations there are other legal grounds/reasons/purposes to request the claims and verification data. Besides ?consent?, the European GDPR indicates other legal grounds (contract, vital interest, legal obligation, ..). When an RP asks for a verified
 claim, it may do so based on a legal obligation and the user?s consent would not be needed.<br class="">
- Privacy regulations aim at situations where personal data is exchanged between legal entities (data controllers, data processors). From an IT perspective, the OP and the RP may be operated by the same entity (for example an Insurance company as data controller
 that is both the data controller for the OP and various RPs) so consent would not apply at the moment of requesting the claim. The consent should already have been given at the moment the personal data was provided to the OP.<br class="">
My proposal would be that the ?purpose? could be a string (as per current specification) or a reference to a ?purpose? that has already been established somewhere. This approach makes it easier for the OP to make the decision to provide the requested data or
 not.<br class="">
</blockquote>
<br class="">
I agree the text is too strong. The purpose should be used to further inform the user in case a user consent screen is required. I will try to change the text accordingly.<br class="">
</blockquote>
<br class="">
Extending my previous replies, my suggestion would be that the eKYC standard would not ?enforce? or assume whatever particular legal set-up of responsibilities, but instead facilitate any legal context and/or interpretation.<br class="">
I think the way to do so would be to include the possibility to include one or more references to types of data processing (?purposes?) that should somehow be legally covered.<br class="">
How this ?legal cover? is arranged for may vary per implementation:<br class="">
- Is the OP Data Controller or Data Processer? Is the RP Data Controller or Data Processer?<br class="">
- Does the intended data processing require the user?s consent or does one of the other legal grounds apply?<br class="">
- Did RP and OP agree on some delegation about getting the user?s consent (if needed)?<br class="">
In this way the protocol can facilitate any set-up in a transparant way, without making assumptions on legal reponsibilities at either OP and/or RP.<br class="">
</blockquote>
<br class="">
 What does this mean to protocol constructs? Can you please suggest concrete changes/text?<br class="">
<br class="">
<blockquote type="cite" class=""><br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
Furthermore, it could be considered to extend the list of verification methods with the ones defined by NISTIR 8112.<br class="">
</blockquote>
<br class="">
You mean ?Document Verification?, ?Record Verification?, ?Document Verification with Record Verification?, ?Proof of Possession?, ?Probabilistic Verification?, ?Not Verified?? We could add this to our Wiki. May I ask you to add the values?<br class="">
</blockquote>
<br class="">
Yes that?s what I meant. I need to familiarize with the wiki.<br class="">
</blockquote>
<br class="">
 You may find the existing definitions at https://bitbucket.org/openid/ekyc-ida/wiki/identifiers.<br class="">
<br class="">
 Let me know if you want to contribute changes, the I would give you the respective permissions.
<br class="">
<br class="">
 best regards,<br class="">
 Torsten. <br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
-- <br class="">
Openid-specs-ekyc-ida mailing list<br class="">
Openid-specs-ekyc-ida@lists.openid.net<br class="">
http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida<br class="">
</blockquote>
<br class="">
</blockquote>
<br class="">
 -- <br class="">
 Openid-specs-ekyc-ida mailing list<br class="">
 Openid-specs-ekyc-ida@lists.openid.net<br class="">
 http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida<br class="">
<br class="">
</blockquote>
<br class="">
-- <br class="">
Openid-specs-ekyc-ida mailing list<br class="">
Openid-specs-ekyc-ida@lists.openid.net<br class="">
http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida<br class="">
</blockquote>
<br class="">
-------------- next part --------------<br class="">
An HTML attachment was scrubbed...<br class="">
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20200525/27ba31dd/attachment.html><br class="">
<br class="">
------------------------------<br class="">
<br class="">
Subject: Digest Footer<br class="">
<br class="">
Openid-specs-ekyc-ida mailing list<br class="">
Openid-specs-ekyc-ida@lists.openid.net<br class="">
http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida<br class="">
<br class="">
<br class="">
------------------------------<br class="">
<br class="">
End of Openid-specs-ekyc-ida Digest, Vol 21, Issue 1<br class="">
****************************************************<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>