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

Torsten Lodderstedt torsten at lodderstedt.net
Sun May 26 16:41:02 UTC 2019

Hi Marcos,

> On 6. May 2019, at 17:35, Marcos Sanz via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> Hi Torsten,
> hi Daniel,
> all,
> this new version has a lot of improvements and is much more readable than 
> the original one. I think this really is progressing!

Thanks. Your review feedback contributed to this improvements a lot! 

> Please allow me 
> again to make a couple of comments/suggestions:
> - Section 1: s/signficantly/significantly/
> - Section 1: the problem with "which requires a different, currently 
> unsupported" is that it looks like the word "which" is referring to the 
> authentication assurance. I't rather read "and requires a different, 
> currently…".

Reworded this sentence in -03

> - Section 1.1: definition both terms, "proofing" and "verification", 
> directly involves the OP as the party carrying the proofing or 
> verification itself, but this is not necessarily the case, and later on 
> the text we learn how this responsibility can be delegated (cf 
> "organization" element in section 4.1.1). Also Claims Providers are a 
> possibility of delegation. What I want to say is: could we extend the 
> definitions of "proofing" and "verification" to say "evidence to an OP or 
> an entity on its behalf"/"conducted by the OP or an entity on its behalf”?

I added "or a claim provider” to all definitions. 

Please note, I removed the "organization” field in -02 because it is redundant:
- if the OP attests the verified person data, the iss claim of the respective assertion already identifies the IDP
- if the verified person data is attested by a claim provider by way of aggregated or distributed claims, the respective JWT will contain another iss claim identifying the claims provider. 

If an organisation conducts the verification on behalf of OP or claims provider, this will be captured in the optional verifier field (new in -03). 

> - Section 1.1: definition of "assurance" says "to provide evidences of the 
> identity proofing process to the RP". But actually it should be "evidences 
> of the identity *verification* process" (later on, section 2 correctly 
> states "more data about the identity verification process" and 
> "externalize information about the identity verification process”).

Thanks, good catch.

> - Section 2: IMHO "this extension will introduce new user claims" should 
> read "this extension MAY introduce new user claims" (as a matter of fact 
> it *does*, but we are still in the requirements section).

Well, the first part of the sentence states “Where necessary,” but the wording you proposed is better :-)

> - Section 2: "There is no need to cover self-asserted claims, or better 
> put claims without further information..." I don't understand the word 
> "better" in this context.

Reworded in -03

> - Section 2: "ensure developers cannot interpret non-verified claims as 
> verified claims". I think it'd be more proper to say "RPs" instead of 
> "developers". And with regard to "non-verified": 50% of the times in the 
> text they are refered like this, the other 50% are "unverified". I think 
> it'd be better to stick to one single denomination.

changed and replaced all occurrences of non-verified by unverified

> - Section 2: This might be nitpicking, but it says "The former, called 
> 'notified eID system' in eIDAS". "The former" can only refer to the 
> previous senence "OPs operating under a regulation" and I wonder what then 
> the 'notified eID system' actually is: the set of all OPs in eIDAS?

A notified eID system is a particular IDP or eID service, such as the German eID. That’s eIDAS terminology :-)

I reworked the whole paragraph. 

> - Section 2: I am missing some statement of relationship to related work 
> in this area (thinking of w3c's Verifiable Claims). Is it a requirement 
> (or a non-requirement) to be compatible to it? (I am sorry, I don't know 
> much about Verifiable Claims).

Is this relevant? 

What do other WG members think?

> - Section 2: It would also be good to have some statement on requirements 
> for extensibility of the solution (and I personally think we should be 
> extensible wrt e.g. additional trust frameworks or verification methods)

Good point, which is already realised but mentioned nowhere :-)

> - Section 3.1: Re "country" this is the only place were ISO 3166-3 is 
> allowed (neither later in the identity_document nor eID country). Is there 
> a rationale for that? Just wondering…

ISO 3166-3 defines identifiers for countries that changed name or ceased to exist, 
e.g. the former GDR. 

Our assumption was the place of birth might be located in a no longer existing country 
while the id document and so on should be issued by an existing country. 

> - 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?

What is your opinion?

> - Section 3.2: Both paragraphs that start with "The OP MUST..." should 
> better move to the requirements section. This way, "transaction_id" claim 
> is just the way of supporting these requirements.

Those are requirements the OP must fulfil if it supports and issues a transaction_id. I modified the wording to make the linkage more obvious.

> - 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. 

Created a corresponding ticket: https://bitbucket.org/openid/connect/issues/1093/extensibility-how-do-we-support

I’m not sure as whether the OP should refuse processing in case it does not recognise a trust framework  (or id document or verification method) identifier. 

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

> - Section 5.1: s/utilzing/utilizing/ and s/Bassically/Basically/


> - Section 5.1: A "requirement for data minimization" is mentioned for the 
> first time, but this requirement is not explicitly listed in section 2. I 
> can imagine this is more of a general requirement, but it might be good to 
> elaborate somewhere what the objective of it is.

Good catch - tried to fold that into the first requirement in section 2

> - Section 5.1: I am a bit scared that the final note "If the claims [...] 
> contains a claim other than the claims listed in the section claims [...], 
> the OP will abort [...] with an invalid_request error" might be 
> detrimental to extensibility of verified data. In my opinion a) the list 
> in section 3.1 should just be initial and b) verified claims in a query 
> which are not understood/supported should be ignored by the OP (in the 
> spirit of OIDC core section 5.1.2). That shouldn't be a problem for RPs, 
> who have to deal anyway with the situation of claims being requested not 
> appearing in the ID token/User Info answer.

That concern was also raised by other reviewers, I therefore already tuned the text in sections 5.1 and 4.2. in -03. Please give it a read.

> - Section 5.2: Maybe s/this mechanics/that mechanism/


> - Section 5.2: "The RP may limit the possible values" and "The RP may also 
> express a requirement regarding the age". I think both "may" should be 
> capitalized.


> - Section 7: "[...] using the claim claims_parameter_supported". I think 
> "using the (configuration) parameter claims_parameter_supported" would be 
> more appropriate.

Revised the sentence

> - 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?

> - 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? 

> - Section 9: s/Marcus/Marcos/ :-)

My apologies! I thought I had tripple checked every name. Fixed now.

> - Section 12.2: s/doccument/document/


Thanks again for the detailed review! I plan to publish the changes soon in the -04 revision. 

best regards,

> Thanks and regards,
> Marcos
>> -02 is live at 
> https://openid.net/specs/openid-connect-4-identity-assurance.html and 
> https://openid.net/specs/openid-connect-4-
>> identity-assurance-02.html.
>>            Thanks Torsten,
>>            -- Mike
>> -----Original Message-----
>> From: Torsten Lodderstedt <torsten at lodderstedt.net> 
>> Sent: Thursday, April 25, 2019 12:50 AM
>> To: Mike Jones <Michael.Jones at microsoft.com>
>> Subject: Opened-connect-4-identity-assurance-02
>> Hi Mike,
>> may I ask you to publish this news revision? 
>> Thanks in Advance, 
>> Torsten. 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- 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/20190526/9bd3f292/attachment.p7s>

More information about the Openid-specs-ab mailing list