<div dir="auto">You may as well just copy the existing piece from the kantara consent receipt. Sorry for the PDF nastiness.<div dir="auto"><br><div dir="auto">5.3 purposes 378 REQUIRED: An array that contains one or more items where each item represents 379 one Purpose. It is only required for the JSON encoding of a Consent Receipt. 380 JSON: purposes, type: array 381 4.5.4 Purpose 382 OPTIONAL: A short, clear explanation of why the PII is required. 383 JSON: purpose, type: string 384 4.5.5 Purpose Category 385 REQUIRED: The reason the PII Controller is collecting the PII. Example Purpose 386 Categories currently in use are available on the Kantara Consent & Information 387 Sharing Work Group (CISWG) Wiki page 388 (<a href="https://kantarainitiative.org/confluence/x/74K-BQ">https://kantarainitiative.org/confluence/x/74K-BQ</a>). This field MUST contain a non-389 empty string. 390 JSON: purposeCate<br></div><div dir="auto"><br><br><div data-smartmail="gmail_signature" dir="auto">thx ..Tom (mobile)</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 14, 2019, 9:57 AM Torsten Lodderstedt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Marcos,<br>
<br>
> On 4. Jun 2019, at 13:18, Marcos Sanz <<a href="mailto:sanz@denic.de" target="_blank" rel="noreferrer">sanz@denic.de</a>> wrote:<br>
> <br>
> Hi Torsten,<br>
> <br>
> (despite subject I am now refering to the latest version -04)<br>
> <br>
>>> - Section 3.1: Re "nationality" it looks like only one country code is <br>
> <br>
>>> allowed. Is it in scope to deal with multiple nationalities?<br>
>> <br>
>> Good question! I will created a corresponding ticket (<br>
> <a href="https://bitbucket.org/openid/connect/issues/1092/support-multiple-nationalities" rel="noreferrer noreferrer" target="_blank">https://bitbucket.org/openid/connect/issues/1092/support-multiple-nationalities</a><br>
> ). <br>
>> <br>
>> There are indeed people having more than a single nationality. <br>
>> The question is whether the IDP will verify those and will be able to <br>
> attest them.<br>
>> <br>
>> In our original setting (German AML), the bank will verify _a_ <br>
> nationality but not <br>
>> necessarily all of them. <br>
>> <br>
>> There is also a structural challenge. If we modify the syntax to allow <br>
> for multiple nationalities, is there a need to link every <br>
>> entry in the array to a certain evidence?<br>
> <br>
> At the moment the spec does not link verified data to its respective <br>
> evidence at all, even when there are multiple evidences (s. for instance <br>
> the example in section 6.2 with ID document AND utility bill), so I don't <br>
> think we would (or actually do) need that capability. On the other hand, <br>
> you might be right with regard to an entity verifying one nationality and <br>
> not all of them. So I don't really need the multiple nationalities <br>
> feature.<br>
> <br>
> What I just came up with and actually think to be more important than <br>
> multiple nationalities (warning: I am not an expert in this topic!) is the <br>
> fact that the ICAO Machine Readable Passports specification asserts <br>
> nationality by means of their ICAO codes (<br>
> <a href="https://www.icao.int/publications/Documents/9303_p3_cons_en.pdf" rel="noreferrer noreferrer" target="_blank">https://www.icao.int/publications/Documents/9303_p3_cons_en.pdf</a>), which <br>
> expand ISO 3166 because they also have to deal with UN travel documents <br>
> and other various issuing authorities. ICAO even reserve nationality codes <br>
> for stateless people.  For a good summary read<br>
> <a href="https://www.iso.org/news/2011/04/Ref1604.html" rel="noreferrer noreferrer" target="_blank">https://www.iso.org/news/2011/04/Ref1604.html</a> rather than the ICAO PDF.<br>
> <br>
> So while ISO3166 initially seemed to us initially like the natural fit to <br>
> describe "issuer country" and "nationality", we might be excluding <br>
> (discriminating?) identities from being describable with our spec.<br>
> <br>
> Are ICAO codes maybe the better way to go?<br>
<br>
Sounds reasonable to me. I created a ticket <a href="https://bitbucket.org/openid/connect/issues/1099/use-icao-codes-for-nationality-and-issuer" rel="noreferrer noreferrer" target="_blank">https://bitbucket.org/openid/connect/issues/1099/use-icao-codes-for-nationality-and-issuer</a> in order to discuss your proposal with the group.<br>
<br>
> <br>
>>> - Section 4.1: If we agree that we should be extensible wrt Trust <br>
>>> Frameworks, a sentence should be included here (or somewhere else) <br>
> that a) <br>
>>> the list in section 12.1 is only the initial list b) that Trust <br>
> Frameworks <br>
>>> that are not understood in answers should be ignored and c) that <br>
> querying <br>
>>> for unknown (i.e. not announced in trust_frameworks_supported) Trust <br>
>>> Frameworks should maybe deliver a dedicated, still to be defined error <br>
> <br>
>>> (e.g. trust framework not supported)<br>
>> <br>
>> Enhanced text a bit. The challenge I see is to really establish the <br>
> required extension mechanism. <br>
> <br>
> Absolutely.<br>
> <br>
>> Created a corresponding ticket: <br>
> <a href="https://bitbucket.org/openid/connect/issues/1093/extensibility-how-do-we-support" rel="noreferrer noreferrer" target="_blank">https://bitbucket.org/openid/connect/issues/1093/extensibility-how-do-we-support</a><br>
> [...]<br>
>> Created another ticket to bring this question to the WG’s attention: <br>
> <a href="https://bitbucket.org/openid/connect/issues/1094/how-to-" rel="noreferrer noreferrer" target="_blank">https://bitbucket.org/openid/connect/issues/1094/how-to-</a><br>
>> treat-unknown-identifiers-in-claims<br>
> <br>
> Ok, let's track discussion there.<br>
> <br>
>>> - Section 8: This is a cool feature, which indeed we use in our <br>
> deployment <br>
>>> (we call it "reason" instead of "purpose", but the same semantics). As <br>
> a <br>
>>> matter of fact, we allow to specify a per-claim "reason" (which is <br>
>>> specially useful to differentiate among why some claims requested are <br>
>>> mandatory and some optional). We query like this (in order to be OIDC <br>
> core <br>
>>> compliant):<br>
>>> "userinfo": { "given_name": {"essential": true, "reason": "In order to <br>
> <br>
>>> create an account"}}<br>
>>> Do you think we could enrich "purpose" in this direction? And in any <br>
> case, <br>
>>> a usage example in section 8 would be helpful.<br>
>> <br>
>> Sure. Can you please suggest text?<br>
> <br>
> Actually I think now that the text, which is all about requesting user <br>
> claims, better belongs to section 5.1, right before the first note (and <br>
> there's no need at all for a section 8):<br>
<br>
I like your proposal! I also think both approaches will perfectly go together. Having a description of the overall purpose of the transaction makes a lot of sense in a lot of use cases, e.g. “I need to obtain this data because you want to sign up for a mobile subscription with me and I need to verify your identity”. On the other hand, having the ability to also state the purpose for acquiring an individual claim is valuable as well. <br>
<br>
So I would like to keep the transaction parameter and added your proposal.<br>
<br>
> <br>
> "<br>
> This specification introduces the request parameter purpose to allow a RP <br>
> to state the purpose for the transfer of the user data it is asking for. <br>
> The parameter purpose can be a member value of each individually requested <br>
> claim, but a claim cannot have more than one associated purpose.<br>
> purpose OPTIONAL. String describing the purpose for obtaining certain user <br>
> data from the OP. The purpose MUST NOT be shorter than 3 characters or <br>
> longer than 300 characters. If this rule is violated, the authentication <br>
> request MUST fail and the OP returns an error invalid_request to the RP.<br>
> The OP MUST display this purpose in the respective user consent screen(s) <br>
> in order to inform the user about the designated use of the data to be <br>
> transferred or the authorization to be approved. Purposes are free text <br>
> and, as such, it is up to the RP to perform localization of the message <br>
> (incl. choosing the appropriate language) according to user <br>
> context/preferences before issuing the request. If the parameter purpose <br>
> is not present in the request, the OP MAY display a generic purpose or a <br>
> value that was pre-configured for the respective RP.<br>
> Example:<br>
<br>
I incorporated your text with an exception, I did not include the option for the OP to display a generic purpose. I cannot imagine how a generic purpose could look like since it always depends on what the RP intends to do with the data. <br>
<br>
> { <br>
>   "userinfo":{ <br>
>      "verified_person_data":{ <br>
>         "claims":{ <br>
>            "given_name":{"essential": true, "purpose": "To make <br>
> communication look more personal"},<br>
>            "family_name":{"essential": true},<br>
>            "birthdate":{"purpose": "To send you best wishes on your <br>
> birthday"}<br>
>         }<br>
>      }<br>
>   } <br>
> }<br>
> "<br>
> <br>
> <br>
>>> - Section 8: What about moving the final Note on XSS and the like to <br>
> the <br>
>>> (still empty) Security Considerations?<br>
>> <br>
>> Well, you are not the first reviewer to raise this. I would like to <br>
> leave it in section 8 for now because moving it into the <br>
>> security considerations section would require to first establish the <br>
> context, … this is about the purpose …<br>
>> <br>
>> I personally prefer to give security considerations with the feature <br>
> description since it is the right context and is directly <br>
>> actionable. If we in the end come to the conclusion the security <br>
> considerations section is the better place (== better for <br>
>> implementers to understand) I will happily move it there. Ok?<br>
> <br>
> Fine by me.<br>
> <br>
> One more thing: I noticed that section 7 introduces a new boolean element <br>
> (verified_person_data_supported) with exactly the same name as the <br>
> existing JSON array containing all claims supported and defined in the <br>
> very same section. That's a recipe for disaster ;-><br>
<br>
I agree. Fixed that.<br>
<br>
Thanks a lot!<br>
Torsten. <br>
<br>
> <br>
> Best regards,<br>
> Marcos<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>