Identity Assurance Section 5.1 on reason for request

[Tom Jones]

section 5.1 suggested addition

All requests for verified claims MUST include a reason code with a value from list:

1. Consent - user must consent
2. Agree - there is an existing agreement between the OP and the Client on the basis for this request
3. Update - there is an existing user consent that allows updates. (typically because of expiry)
4. Legal - there is a legal requirement to get the data (do we need more of a reason?)
5. Federation - There is an existing multiparty agreement that applies to this request.
6. Private - There MUST be no notification to the user for legal reasons.

The default case is that the user MUST be given opt-in consent on every transfer of the credential information and will receive a receipt of every transfer of information. This field MUST be honoured by the OP or the request MUST be denied.

This is in response to a comment that Nat made at the meeting. There may be a better set of terms that these

[Michael Jones]

I strongly disagree with requiring this value. The claims (and meta-claims) exchanged between parties about the end-user should be entirely up to them. It's our job to define syntax - not to mandate policy.

All claims about the end-user have always been optional in Connect. We shouldn't start changing that now.

[Tom Jones]

I am not sure how this mandates a claim - please explain so i can fix the text.

[Tom Jones]

This may be a requirement is some jurisdictions. I am willing to accept changing the word MUST to RECOMMENDED to handle the more general case.

[Tom Jones]

Mike Jones was skeptical about the need for this type of metadata. This article shows that the cost of ignoring the need to report to users can be an existential threat to the corporation. https://techcrunch.com/2019/03/30/covert-data-scraping-on-watch-as-eu-dpa-lays-down-radical-gdpr-red-line/

[Michael Jones]

A concrete proposal is needed. Mike suggested privacy considerations text on both parties needing to understand the legal basis for information sharing. Tom agreed to write something down.

[Nat Sakimura]

Formatting change.

[Torsten Lodderstedt]

@Tom Jones

We discussed this ticket in the call today. We think the objective of this ticket is achieved by the purpose parameter and claims attribute as specified in the draft. We suggest to resolve this ticket. Ok?

[Victor Herraiz]

We are using a purpose field in plain language to convey that information in a lenient way.

[Torsten Lodderstedt]

Does your approach fit this https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#rfc.section.8?

[Victor Herraiz]

we use “purpose” at several levels: the claim, the full request, the proof request. We are also thinking on add a language (e.g: “lang”: “en-UK”) parameter to avoid any mismatch in the consent process. in the language is not supported by the OPs, they may show default texts.

[Torsten Lodderstedt]

claims are supported by OpenID Connect for Identity Assurance as well https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#rfc.section.5.1

What do you mean with “proof request”?

[Victor Herraiz]

Sorry, at the moment we are using zero-knowledge proofs as describe at https://www.w3.org/TR/vc-data-model/ this is an extension that we did and we are thinking on migrating to identity assurance but we need to review it. What I trying to convey is that we using purpose at several levels (e.i why RP wants this specific piece of data, evidence or full request), but I used a bad example.

[Torsten Lodderstedt]

I got your message I tried to convey that OIDC4IDA supports purpose on several (two) levels.

[Torsten Lodderstedt]

this requirement is covered by the purpose feature on request and claim level.