[OpenID-Specs-eKYC-IDA] Fwd: Usage of scopes and purposes when requesting verified claims

Torsten Lodderstedt torsten at lodderstedt.net
Fri May 1 09:30:43 UTC 2020

Hi Jaap,

thanks for your post. Please find my comments inline.

best regards,

Jaap Francke via Openid-specs-ekyc-ida <
openid-specs-ekyc-ida at lists.openid.net> schrieb am Mi. 29. Apr. 2020 um

> Hi,
> Meanwhile, we’ve signed the IPR paperwork, so I’m re-submitting my
> feedback.
> Kind regards,
> Jaap
> Begin forwarded message:
> *From: *Jaap Francke <jaap.francke at iwelcome.com>
> *Subject: **Usage of scopes and purposes when requesting verified claims*
> *Date: *31 March 2020 at 18:01:32 CEST
> *To: *openid-specs-ekyc-ida at lists.openid.net
> Hi everybody,
> I’m new on this mailing list, thanks for letting me in ;-).
> I have potentially missed previous feedback or conversation around the
> Identity Assurance specification, but that shouldn’t stop me from sharing
> my views.
> As a Product Manager at iWelcome, I am very interested in Identity
> Assurance. I’ve been involved in a number of projects where verified claims
> are a key element to the identity management solution. In the Netherlands,
> for example, consumer banks are using the IDIN schema to act as a claim
> provider for identity proofing purposes.
> This is beneficial to Insurance companies that can sell certain products
> only to proven identities.
> My feedback on the specs is below, I’m interested to see your responses,
> thanks.
> Kind regards
> Jaap Francke
> CIAM Product manager @ iWelcome.
> ———
> https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html
> The "OIDC for identity Assurance” specs introduce a number of claims, in
> addition to the ones specificied by OIDC core.
> In OIDC Core, there are 2 mechanisms to request claims:
> - one is by usage of OAuth-scopes, (section 5.4 of Core spec)
> - one by usage of the “claims” parameter in the request. (section 5.5 of
> Core spec)
> Section 5 of the OIDC—identity-assurance specs indicate the usage of the
> claims pararameter. This may suggest it’s the only mechanism to be used in
> the context of Identity Assurance.
> My view is that also the ’scope’ mechanism should be supported and may
> even be preferred for certain use cases.
> *Please enhance the specification to be more explicit about usage of
> scopes as a means to request verified claims.*
> Usage of ’scope’ to request verified claims makes sense to me because in a
> typical “identity landscape” the requested claims do not vary on a
> request-by-request basis, but instead are a reflection of an RP’s
> functionality which can be rather static. By pre-defining/configuring
> scopes at the OP (potentially in terms of ’essential’, ’trust_framework’,
> etc..), the scope is essentially a profile of the claim request. This would
> not only simplify the protocol implementation both at the RP and OP side,
> but it would also make it easier for the OP to make the authorisation
> decision whether or not the RP will be granted the requested verified
> claims. 'It is at the discretion of the OP to decide whether the
> requested verification data is provided to the RP.’ Making this decision
> is much easier when a request includes a scope as a reference to a
> predefined profile of requested end-user claims and associated verification
> data. *My suggestion is to consider including such a mechanism in the
> specifications.*
What do you have in mind? I agree a certain RP or deployment could define
scope values as short cut to request certain verified claims. However, the
number and value range of verification elements + the number of end user
claims creates is so big I cannot envision how the spec could define
concrete scope values. Additionally, the spec no longer defines values for
trust frameworks, verification methods and evidence, i.e. there are unknown
values from a spec perspective.

> My second observation is about the optional ‘purpose’ parameter in a
> claims request. The specs state that the OP MUST display this purpose in
> the respective user consent screen(s) in order to inform the user about the
> designated use of the data to be transferred or the authorization to be
> approved. If the parameter purpose is not present in the request, the OP
> MAY display a value that was pre-configured for the respective RP.’
> This part of the specification assumes or seems to imply that the user
> gets a consent screen every time that verified data is requested. I think
> that this is not realistic:
> - it is common practice that certain consents are included in a Privacy
> Policy (PP) and/or Terms of Service (ToS). The user gives his consent once
> and the consent is persisted at the OP for future purposes.
Are you referring to ToS/PP of the RP or the OP?

> - if not in PP or ToS, a consent screen may be presented only ‘once’ and
> the user’s consent is taken to be valid for the next 6 months (as an
> example)
> - in some situations there are other legal grounds/reasons/purposes to
> request the claims and verification data. Besides ‘consent’, the European
> GDPR indicates other legal grounds (contract, vital interest, legal
> obligation, ..). When an RP asks for a verified claim, it may do so based
> on a legal obligation and the user’s consent would not be needed.
> - Privacy regulations aim at situations where personal data is exchanged
> between legal entities (data controllers, data processors). From an IT
> perspective, the OP and the RP may be operated by the same entity (for
> example an Insurance company as data controller that is both the data
> controller for the OP and various RPs) so consent would not apply at the
> moment of requesting the claim. The consent should already have been given
> at the moment the personal data was provided to the OP.
> *My proposal would be that the ‘purpose’ could be a string (as per current
> specification) or a reference to a ‘purpose’ that has already been
> established somewhere.* This approach makes it easier for the OP to make
> the decision to provide the requested data or not.
I agree the text is too strong. The purpose should be used to further
inform the user in case a user consent screen is required. I will try to
change the text accordingly.

> *Furthermore, it could be considered to extend the list of verification
> methods with the ones defined by NISTIR 8112.*
You mean „Document Verification”, “Record Verification”, “Document
Verification with Record Verification”, “Proof of Possession”,
“Probabilistic Verification”, „Not Verified”? We could add this to our
Wiki. May I ask you to add the values?

> --
> Openid-specs-ekyc-ida mailing list
> Openid-specs-ekyc-ida at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20200501/406dc98e/attachment-0001.html>

More information about the Openid-specs-ekyc-ida mailing list