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

Marcos Sanz sanz at denic.de
Mon May 6 15:35:06 UTC 2019


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! 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...".
- 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"?
- 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").
- 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).
- 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.
- 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.
- 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?
- 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).
- 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)
- 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...
- Section 3.1: Re "nationality" it looks like only one country code is 
allowed. Is it in scope to deal with multiple nationalities?
- 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.
- 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)
- 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.
- 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.
- 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.
- 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.
- Section 8: What about moving the final Note on XSS and the like to the 
(still empty) Security Considerations?
- Section 9: s/Marcus/Marcos/ :-)
- Section 12.2: s/doccument/document/

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



More information about the Openid-specs-ab mailing list