- edited description
Identity Assurance Section 5.1 on reason for request
section 5.1 suggested addition
All requests for verified claims MUST include a reason code with a value from list:
- Consent - user must consent
- Agree - there is an existing agreement between the OP and the Client on the basis for this request
- Update - there is an existing user consent that allows updates. (typically because of expiry)
- Legal - there is a legal requirement to get the data (do we need more of a reason?)
- Federation - There is an existing multiparty agreement that applies to this request.
- 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
Comments (18)
-
reporter -
reporter - edited description
-
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.
-
reporter I am not sure how this mandates a claim - please explain so i can fix the text.
-
reporter 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.
-
reporter 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/
-
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.
-
- edited description
Formatting change.
-
@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?
-
We are using a purpose field in plain language to convey that information in a lenient way.
-
Does your approach fit this https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#rfc.section.8?
-
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.
-
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”?
-
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.
-
I got your message I tried to convey that OIDC4IDA supports purpose on several (two) levels.
-
- changed milestone to Amendment
-
- removed milestone
-
- changed status to resolved
this requirement is covered by the purpose feature on request and claim level.
- Log in to comment