[Openid-specs-ab] Opened-connect-4-identity-assurance-02

Sun Jul 14 16:57:15 UTC 2019

Hi Marcos,

> On 4. Jun 2019, at 13:18, Marcos Sanz <sanz at denic.de> wrote:
> 
> Hi Torsten,
> 
> (despite subject I am now refering to the latest version -04)
> 
>>> - Section 3.1: Re "nationality" it looks like only one country code is 
> 
>>> allowed. Is it in scope to deal with multiple nationalities?
>> 
>> Good question! I will created a corresponding ticket (
> https://bitbucket.org/openid/connect/issues/1092/support-multiple-nationalities
> ). 
>> 
>> There are indeed people having more than a single nationality. 
>> The question is whether the IDP will verify those and will be able to 
> attest them.
>> 
>> In our original setting (German AML), the bank will verify _a_ 
> nationality but not 
>> necessarily all of them. 
>> 
>> There is also a structural challenge. If we modify the syntax to allow 
> for multiple nationalities, is there a need to link every 
>> entry in the array to a certain evidence?
> 
> At the moment the spec does not link verified data to its respective 
> evidence at all, even when there are multiple evidences (s. for instance 
> the example in section 6.2 with ID document AND utility bill), so I don't 
> think we would (or actually do) need that capability. On the other hand, 
> you might be right with regard to an entity verifying one nationality and 
> not all of them. So I don't really need the multiple nationalities 
> feature.
> 
> What I just came up with and actually think to be more important than 
> multiple nationalities (warning: I am not an expert in this topic!) is the 
> fact that the ICAO Machine Readable Passports specification asserts 
> nationality by means of their ICAO codes (
> https://www.icao.int/publications/Documents/9303_p3_cons_en.pdf), which 
> expand ISO 3166 because they also have to deal with UN travel documents 
> and other various issuing authorities. ICAO even reserve nationality codes 
> for stateless people.  For a good summary read
> https://www.iso.org/news/2011/04/Ref1604.html rather than the ICAO PDF.
> 
> So while ISO3166 initially seemed to us initially like the natural fit to 
> describe "issuer country" and "nationality", we might be excluding 
> (discriminating?) identities from being describable with our spec.
> 
> Are ICAO codes maybe the better way to go?

Sounds reasonable to me. I created a ticket https://bitbucket.org/openid/connect/issues/1099/use-icao-codes-for-nationality-and-issuer in order to discuss your proposal with the group.

> 
>>> - Section 4.1: If we agree that we should be extensible wrt Trust 
>>> Frameworks, a sentence should be included here (or somewhere else) 
> that a) 
>>> the list in section 12.1 is only the initial list b) that Trust 
> Frameworks 
>>> that are not understood in answers should be ignored and c) that 
> querying 
>>> for unknown (i.e. not announced in trust_frameworks_supported) Trust 
>>> Frameworks should maybe deliver a dedicated, still to be defined error 
> 
>>> (e.g. trust framework not supported)
>> 
>> Enhanced text a bit. The challenge I see is to really establish the 
> required extension mechanism. 
> 
> Absolutely.
> 
>> Created a corresponding ticket: 
> https://bitbucket.org/openid/connect/issues/1093/extensibility-how-do-we-support
> [...]
>> Created another ticket to bring this question to the WG’s attention: 
> https://bitbucket.org/openid/connect/issues/1094/how-to-
>> treat-unknown-identifiers-in-claims
> 
> Ok, let's track discussion there.
> 
>>> - Section 8: This is a cool feature, which indeed we use in our 
> deployment 
>>> (we call it "reason" instead of "purpose", but the same semantics). As 
> a 
>>> matter of fact, we allow to specify a per-claim "reason" (which is 
>>> specially useful to differentiate among why some claims requested are 
>>> mandatory and some optional). We query like this (in order to be OIDC 
> core 
>>> compliant):
>>> "userinfo": { "given_name": {"essential": true, "reason": "In order to 
> 
>>> create an account"}}
>>> Do you think we could enrich "purpose" in this direction? And in any 
> case, 
>>> a usage example in section 8 would be helpful.
>> 
>> Sure. Can you please suggest text?
> 
> Actually I think now that the text, which is all about requesting user 
> claims, better belongs to section 5.1, right before the first note (and 
> there's no need at all for a section 8):

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. 

So I would like to keep the transaction parameter and added your proposal.

> 
> "
> This specification introduces the request parameter purpose to allow a RP 
> to state the purpose for the transfer of the user data it is asking for. 
> The parameter purpose can be a member value of each individually requested 
> claim, but a claim cannot have more than one associated purpose.
> purpose OPTIONAL. String describing the purpose for obtaining certain user 
> data from the OP. The 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 returns an error invalid_request to the RP.
> 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. Purposes are free text 
> and, as such, it is up to the RP to perform localization of the message 
> (incl. choosing the appropriate language) according to user 
> context/preferences before issuing the request. If the parameter purpose 
> is not present in the request, the OP MAY display a generic purpose or a 
> value that was pre-configured for the respective RP.
> Example:

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. 

> { 
>   "userinfo":{ 
>      "verified_person_data":{ 
>         "claims":{ 
>            "given_name":{"essential": true, "purpose": "To make 
> communication look more personal"},
>            "family_name":{"essential": true},
>            "birthdate":{"purpose": "To send you best wishes on your 
> birthday"}
>         }
>      }
>   } 
> }
> "
> 
> 
>>> - Section 8: What about moving the final Note on XSS and the like to 
> the 
>>> (still empty) Security Considerations?
>> 
>> Well, you are not the first reviewer to raise this. I would like to 
> leave it in section 8 for now because moving it into the 
>> security considerations section would require to first establish the 
> context, … this is about the purpose …
>> 
>> I personally prefer to give security considerations with the feature 
> description since it is the right context and is directly 
>> actionable. If we in the end come to the conclusion the security 
> considerations section is the better place (== better for 
>> implementers to understand) I will happily move it there. Ok?
> 
> Fine by me.
> 
> One more thing: I noticed that section 7 introduces a new boolean element 
> (verified_person_data_supported) with exactly the same name as the 
> existing JSON array containing all claims supported and defined in the 
> very same section. That's a recipe for disaster ;->

I agree. Fixed that.

Thanks a lot!
Torsten. 

> 
> Best regards,
> Marcos

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3923 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190714/c49146eb/attachment.p7s>