Expression Language

[Torsten Lodderstedt]

This is a spin up from #1172 to have a ticket representing our work towards support for derived claims based on expressions defined by the RP.

[Alberto Pulido Moyano]

I would like to share a preview of the specs, they could be found here.

Meanwhile we move the specs to this repo, please feel free to provide feedback and open issues in this repo.

[Alberto Pulido Moyano]

Hi, I've been sharing some thoughts with @Anthony nadalin regarding the available operations for such a expression language proposal. In the specs that I shared above, there are references to example operators. It is also explained how those operators and the claim types that can be applied to, is available so that the OP can express its own set of operators within the discovery endpoint.

Question for the group:

Do you think that as part of the eKYC-ida specs, we could come with a simple and prefixed set of operands fit for purpose? Or should we leave it open and let implementers decide their own?

‌

An example and proposal for a minimum set of operands could be something like this:

‌

eq: The value is equal to the given value.

gt: The value should be greater than the given value.

lt: The value should be lower than the given value.

gte: The value is equal or greater than the given value.

lte: The value is equal or lower than the given value.

in: The value is equal to one of the elements in the given list.

or: The value pass any of the given expressions

some: The value is equal to any of the values within an array

none: The value is not equal to any of the values within an array

every: The value is equal to all of the values within an array

‌

‌

[Mark Haine]

Google are using the following for handling exprressions when authorising access

https://github.com/google/cel-spec

any views?

[Alberto Pulido Moyano]

Hi @Mark Haine , I think that it is a great spec, however maybe we don't need all that complexity. I'm also not very sure about having an external dependency not targeted for KYC-ida purposes. I still believe is this WG the best fit for purpose when looking into defining such extension.

As we agreed on last meeting, we could think about some example use cases to help us scoping the expression language. I will add some examples in a following comment to this issue.

‌

[Alberto Pulido Moyano]

Here you have some example expressions for assertions, some of them could be applied on top of the claims already defined by OpenID Connect or eKYC-ida, but also allow me to add examples on other potential claims some OPs may be able to resolve:

‌

• Does End-User last name and first name match with the given details?
• Does End-User have one of these nationalities?
• Does End-User live in this city?
• Do this telephone and email belong to the End-User?
• Is the End-User older than 65?
• Does End-User have a bank account with this IBAN details?
• Does End-User have more than X yearly income?
• Does End-User have a valid UK Driving License?
• Does End-User spend more than X in utility bills?
• Is the End-User the owner of the property under this address?
• Is this End-User passport expired?
• Did the End-User travel abroad in the last 6 months to one of these countries?
• Is the End-User qualified to authorise this payment on behalf of this company name?
• Does the End-User work for this company?

‌

Please feel free to add/delete/amend any to the above examples, the idea is not to think of course on all possible use cases, but somehow those where it makes sense providing assertions to protect user privacy. The main intention with the list is to have a feeling on the type of operations on claims we could think of.

‌

[Mark Haine]

From the perspective of privacy I think it would be good to be able to return a single boolean response in certain circumstances even if the conditions combine multiple attributes at the OP.

As an example a conditional request might be to confirm that the subject lives at a given address and has a valid drivers license.

From a data minimisation perspective this would be best served by a single boolean response.

A second thought about this is how complex can we permit this to get? complex conditions applying to many claims perhaps?

This ties back into the question of how complex this could become and ultimately having a clearly defined boundary of what we are wishing to enable with the conditional claims capability should drive the capability we deliver.

[Mark Haine]

@Alberto Pulido Moyano Regarding external dependancies on some other spec, I understand your concern but I also think that there are significant drawbacks to inventing a new language for this purpose if there are existing solutions that we could use with mature implementations and that have already passed the test in real world scanarios.

[Kai Lehmann]

I believe there is some mixup between OP and RP in the privacy considerations section of the spec proposal. I took the liberty in creating a PR to address this.

[Kristina Yasuda]

There is a similar concept of derived predicates in W3C Verifiable Credentials specification.

https://www.w3.org/TR/vc-data-model/#dfn-predicates

derived predicate

A verifiable, boolean assertion about the value of another attribute in a verifiable credential. These are useful in zero-knowledge-proof-style verifiable presentations because they can limit information disclosure. For example, if a verifiable credential contains an attribute for expressing a specific height in centimeters, a derived predicate might reference the height attribute in the verifiable credential demonstrating that the issuer attests to a height value meeting the minimum height requirement, without actually disclosing the specific height value. For example, the subject is taller than 150 centimeters.

[Alberto Pulido Moyano]

Hi @Kristina Yasuda , I couldn’t find the specification or proposal for how to express the derived predicates. Do you have more information about it or maybe know about someone actually implementing that feature?

[Kristina Yasuda]

this is the most detailed I’ve seen..

https://w3c.github.io/vc-imp-guide/#predicates

‌

[Kristina Yasuda]

We had some discussion at w3c verifiable credentials wg mailing list and there was a lot of interest in the topic. However, because there is no concrete draft/implementation on w3c side, I do not see a need for a joint wg with OIDF.

Presentation exchange spec being worked on in DIF (decentralized identity foundation) can realize selective disclosure using “rule“, “count“, “from“ properties, but it is work in progress, and I would not recommend using it especially in finance industry just yet. https://identity.foundation/presentation-exchange/

Overall, I think we can proceed with discussion in this group, as long as convergence with other initiatives in the space in the mid-long term is kept in mind..

[Alberto Pulido Moyano]

Hi All, please see attached the document I have presented today in the WG session, it includes the summary with key findings and some examples based on above use cases.

I appreciate your feedback during the meeting!.

I hope that helped to evaluate whether or not a more complex language could favour in opposition to a more simple one. I think it’s worth having more feedback and the key is to test the language against real use cases and have into considerations and leverage aspects such as privacy, usability and implementation complexity.

[Mark Haine]

Moved to the AB/Connect Working Group