Spec does not allow the OP to explicitly state how the user has been verified as the owner of the claims

[Julian White]

Current draft does not allow the explicitly OP to say how a user has been bound to the identity taken from the evidence. Its somewhat implied in the ID_Document by the ‘method' however that is relies on a number of assumptions which don’t carry through to other types of ID evidence.

The ‘method’ element explicitly says it is a description of how the evidence was verified not how the user has been verified as its owner, i.e. its testing its authenticity. However the ‘methods’ predefined values do go into those things which seems contradictory to the definition of ‘method’.

For example if the proofing process was doing a lookup from a national population register it is not clear how you would express if the user was verified by that register by a biometric match against a centrally held template, or done over the phone by asking them “security questions”. Both processes are valid, and in both instances we are absolutely sure the claimed identity exists because its in the population register, however the strength or confidence in the user being the owner of that identity varies.

This unravels more when you have more than one piece of ID evidence. In the example given of using an ID document and a utility bill we are implying that the user has had their face compared to the ID document, however if they were asked to post in the ID document and asked questions about the utility (e.g. previous usage or balances) as a method of verification its not clear how the OP would express that.

I suggest we create two fields, one that covers the provenance or authenticity of the evidence. and one for the binding of the user to it. You could put this binding either in each evidence where a user was matched to it, or as one field in the verification element. My preference would be to be able to add it into each evidence as it allows the OP to express whether they have matched them to one or more evidences, and its also clear to the RP which things were used for the binding and which were used as supporting or corroborating evidences.

This is basically the point of the “validation” and “verification” steps in 800-63A.

[Julian White]

In the meeting we agreed that we should create two new fields, “validation_method” and “verification_method” and allow an OP to use them instead of the “method”. They can still use “method” but we need to update its definition.

[Julian White]

I was in the process of updating the specification when I’ve come across and issue with what we currently have written in OP Metadata it currently says:

The OP advertises its capabilities with respect to verified Claims in its openid-configuration (see [@!OpenID-Discovery]) using the following new elements:

`verified_claims_supported`: Boolean value indicating support for `verified_claims`, i.e. the OpenID Connect for Identity Assurance extension.

`trust_frameworks_supported`: JSON array containing all supported trust frameworks.

`evidence_supported`: JSON array containing all types of identity evidence the OP uses.

`id_documents_supported`: JSON array containing all identity documents utilized by the OP for identity verification.

`id_documents_verification_methods_supported`: JSON array containing the ID document verification methods the OP supports as defined in (#verification).

`claims_in_verified_claims_supported`: JSON array containing all claims supported within `verified_claims`.

`attachments_supported`: JSON array containing all attachment types supported by the OP. Possible values are `external` and `embedded`. If the list is empty, the OP does not support attachments.

`digest_algorithms_supported`: JSON array containing all supported digest algorithms which can be used as `alg` property within the digest object of external attachments. If the OP supports external attachments, at least the algorithm `sha-256` MUST be supported by the OP as well. The list of possible digest/hash algorithm names is maintained by IANA in [@!hash_name_registry] (established by [@?RFC6920]).

‌

It uses `id_documents_verification_methods_supported` to describe one of the OP capabilities, which is very close to the new verification_methodelement and could be confusing. However the current specification seems inconsistent with how the other capabilities are named, which appears to be [element]_supported but there is no verification_method in the current specification, its just called method. It would seem that for this to be consistent with the rest of the document it should be called id_documents_methods_supported but changing that would be a breaking change if it were being used. On the WG call no one knew of any implementations that was actually using this so it may not actually break anything.

Mark (@Mark Haine ) suggested this should be discussed with Torsten (@Torsten Lodderstedt ) to try and find a way to fix or work around this.

‌

[Torsten Lodderstedt]

Thanks for identifying this inconsistency. I basically agree with the proposed name change. However, before moving forward, we (yes.com) need to check back with our Implementors re the required changes.

[Torsten Lodderstedt]

We checked backed and it seems the impact is acceptable. So please go ahead as proposed.

[Julian White]

Pull request (#74) created.

[Mark Haine]

Resolved by PR#74