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

[Marcos Sanz]

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?

> > - 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):

"
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:
{ 
   "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 ;->

Best regards,
Marcos