RE: Re: [EXTERNAL] Re: "Derivative predicate" of W3C VC WG and "Expression Language" of OIDF ekyc-ida WG

I am not sure I fully understand the issues in the bullet points you listed below for “Extensible”, “Safe”, and “Easy to translate to natural language”. Can you help clarify why something like a phone number would not work as an addition to the set of built-in formats (https://json-schema.org/understanding-json-schema/reference/string.html#built-in-formats) for something like JSON Schema? I understand that regex eval can be a vector for certain processing/perf issues when evaluating regexes from untrusted userland parties, but given a set of types for common ZKP circuits would need to be standardized, and their type/value parsing logic strictly codified, why would such an issue exist for the standard type system and those using libraries coded to evaluate that type system? I am not really clear on the last bullet, but an example that shows how one would ‘not know what is going on’ vs ‘know what is going on’, might help.

- Daniel

From: Herraiz, Victor (SanTech) <victor.herraiz@santander.co.uk>
Sent: Thursday, July 16, 2020 4:22 AM
To: Pulido Moyano, Alberto <alberto.pulido@santander.co.uk>; Kristina Yasuda <Kristina.Yasuda@microsoft.com>; Wayne Chang <wyc@fastmail.fm>; Daniel Buchner <Daniel.Buchner@microsoft.com>; W3C Credentials CG <public-credentials@w3.org>; Brent Zundel <brent.zundel@evernym.com>; Dave Longley <dlongley@digitalbazaar.com>; Tobias Looker <tobias.looker@mattr.global>; Boothby, Roderick <roderick.boothby@gruposantander.com>; Anthony Nadalin <tonynad@microsoft.com>; Mark Haine <mark@considrd.consulting>
Subject: Re: Re: [EXTERNAL] Re: "Derivative predicate" of W3C VC WG and "Expression Language" of OIDF ekyc-ida WG

Hello everyone,

We considered many alternatives for the design of the assertion language, but first of all the name. Predicate is indeed a better name, false or true are both valid outcomes. On the other hand Assertions could be interrelated as the only valid option is true and false is a failure.

About the expression language, we consider different approaches:


  *   MongoDB “where” language
  *   JSON Schema types and constrains.
  *   A Expression language like Spring EL

At the end we choose something like the mongodb query syntax but without the problem of mixing operands and literals that gave them so many problems.

Some of the requirements were:

  *   Extensible: Adding types like phone_number that require a normalization before execution without including this massive dependencies.
  *   Safe: For example, regular expression are forbidden to avoid ReDoS.
  *   Easy to translate to natural language: The owner of the data must know what is going on… 😃

JSON Schema was discarded for those reasons and because the scope of the language is validation not a simple predicate. The current implementations are bind to that rule.




From: "Pulido Moyano, Alberto" <alberto.pulido@santander.co.uk<mailto:alberto.pulido@santander.co.uk>>
Date: Thursday, 16 July 2020 at 11:45
To: Kristina Yasuda <Kristina.Yasuda@microsoft.com<mailto:Kristina.Yasuda@microsoft.com>>, Wayne Chang <wyc@fastmail.fm<mailto:wyc@fastmail.fm>>, Daniel Buchner <Daniel.Buchner@microsoft.com<mailto:Daniel.Buchner@microsoft.com>>, W3C Credentials CG <public-credentials@w3.org<mailto:public-credentials@w3.org>>, Brent Zundel <brent.zundel@evernym.com<mailto:brent.zundel@evernym.com>>, Dave Longley <dlongley@digitalbazaar.com<mailto:dlongley@digitalbazaar.com>>, Tobias Looker <tobias.looker@mattr.global<mailto:tobias.looker@mattr.global>>, "Herraiz, Victor (SanTech)" <victor.herraiz@santander.co.uk<mailto:victor.herraiz@santander.co.uk>>, "Boothby, Roderick" <roderick.boothby@gruposantander.com<mailto:roderick.boothby@gruposantander.com>>, Anthony Nadalin <tonynad@microsoft.com<mailto:tonynad@microsoft.com>>, Mark Haine <mark@considrd.consulting<mailto:mark@considrd.consulting>>
Subject: Re: #External Sender# Re: [EXTERNAL] Re: "Derivative predicate" of W3C VC WG and "Expression Language" of OIDF ekyc-ida WG

Hi Kristina and all,

Thanks for looping me in, also adding Victor and Rod to the thread.

I include as well Anthony and Mark, since they are helping moving forward this issue under eyk-ida WG.

We did this specification with the intention to create an extension to OpenId, where a new type of claims (assertions/predicates)  is in place, so that user privacy is enhanced.

It is part of a wider set of specs we´ve been working as a research project and based on actual use cases we have identified that could work for us. However, we are trying to contribute and reach to a wider community to see if some of those ideas help providing standards for solving similar problems that W3C VC solves. Actually, we always though somehow we could provide the transport layer for Verifiable Credentials in a form of proof or evidence in case the RP demands it, always associated with the request for a particular verified claim/set of claims. Our aim is as well to influence the great work done by the ekyc-ida WG, were we are actively contributing.

The overall Santander project public documentation can be found here: https://gruposantander.github.io/digital-trust-docs/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgruposantander.github.io%2Fdigital-trust-docs%2F&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cc928520695404cb308c108d8297a7942%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304954009385452&sdata=8ZtdzqlyF5Q%2FN%2B7nhRU0F3gXv0s4in6KF7%2FlB8ADL9E%3D&reserved=0>

Regarding assertions (maybe derivative predicates it´s even a better name for what we did!), we defined the specs to be extensible so that each OP defines their own claim types and supported operands, and leaving the implementation of the spec with their own rules. For instance, when implementing the phone_number operand for “eq”, we did plugin a library from google (google-libphonenumber) to normalize the data before comparing the data.


Happy to jump into a call and provide more info if needed, I do see great opportunity now that we are connected thanks to Kristina and Mark!

Kind regards

[cid:image001.png@01D65B42.BDDE4D00]
[cid:image002.png@01D65B42.BDDE4D00]
Alberto Pulido
Technical Expert
Innovation Hub
+44 (0)7710 380 464
Milton Keynes, UK



From: Kristina Yasuda <Kristina.Yasuda@microsoft.com<mailto:Kristina.Yasuda@microsoft.com>>
Date: Thursday, 16 July 2020 at 09:56
To: Wayne Chang <wyc@fastmail.fm<mailto:wyc@fastmail.fm>>, Daniel Buchner <Daniel.Buchner@microsoft.com<mailto:Daniel.Buchner@microsoft.com>>, W3C Credentials CG <public-credentials@w3.org<mailto:public-credentials@w3.org>>, Brent Zundel <brent.zundel@evernym.com<mailto:brent.zundel@evernym.com>>, Dave Longley <dlongley@digitalbazaar.com<mailto:dlongley@digitalbazaar.com>>, Tobias Looker <tobias.looker@mattr.global<mailto:tobias.looker@mattr.global>>, Alberto Pulido Moyano <alberto.pulido@santander.co.uk<mailto:alberto.pulido@santander.co.uk>>
Subject: #External Sender# Re: [EXTERNAL] Re: "Derivative predicate" of W3C VC WG and "Expression Language" of OIDF ekyc-ida WG

+ Alberto who wrote the expression language spec.

If derivative predicates and expression language are trying to achieve the same (looks like they are, correct me if I am wrong), can derivative predicates also be achieved via modifications to JSON Schema?


________________________________
差出人: Wayne Chang <wyc@fastmail.fm<mailto:wyc@fastmail.fm>>
送信日時: 2020年7月16日 12:43
宛先: Daniel Buchner <Daniel.Buchner@microsoft.com<mailto:Daniel.Buchner@microsoft.com>>; Kristina Yasuda <Kristina.Yasuda@microsoft.com<mailto:Kristina.Yasuda@microsoft.com>>; W3C Credentials CG <public-credentials@w3.org<mailto:public-credentials@w3.org>>; Brent Zundel <brent.zundel@evernym.com<mailto:brent.zundel@evernym.com>>; Dave Longley <dlongley@digitalbazaar.com<mailto:dlongley@digitalbazaar.com>>; Tobias Looker <tobias.looker@mattr.global<mailto:tobias.looker@mattr.global>>
件名: Re: [EXTERNAL] Re: "Derivative predicate" of W3C VC WG and "Expression Language" of OIDF ekyc-ida WG

That's an interesting proposal to extend JSON Schema. If one day it gets promoted to an IETF standard from its draft status, that might get easier to do. I'm curious about the direction of supporting things like references to ISO currency codes (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fiso-4217-currency-codes.html&amp;data=02%7C01%7CKristina.Yasuda%40microsoft.com%7Cf4fcb1e315dc442a258808d8293a6aeb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304678180868210&amp;sdata=b3t5XY%2FHT0zaSV%2B0oO8VPreNTKC1wu96SrwHkIHH2HY%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fiso-4217-currency-codes.html&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cc928520695404cb308c108d8297a7942%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304954009395447&sdata=og3KCL5RhS5yvj%2FKNFBSMqhABpGAbA8GjBIJUnW8JD0%3D&reserved=0>) in some kind of claims request language, and URI-referenced validation operations on top of that. JSON Schema is focused on validating JSON Document structures only, so this direction might be out of scope for it (and admittedly I'm pretty ignorant around JSON Hyper-Schema for which I haven't been able to find many well-supported libraries, and also not sure about its possible relationship to JSON-LD for that matter).

Furthermore, if the validation operators have special rules around processing typed values (for example, "the given HTTPS URL must be CA root cert-valid and resolve to 200 OK"), then it would probably have to live in a separate use case-specific extension to JSON Schema or other form of operator definition.

I think a similar conversation in Presentation Exchange involves the specification of trust frameworks hosted somewhere else:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdecentralized-identity%2Fpresentation-exchange%2Fissues%2F24&amp;data=02%7C01%7CKristina.Yasuda%40microsoft.com%7Cf4fcb1e315dc442a258808d8293a6aeb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304678180868210&amp;sdata=i6KZbndzraspRu9zs05drOfQuBtdg%2Bqu384JihBcgd0%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdecentralized-identity%2Fpresentation-exchange%2Fissues%2F24&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cc928520695404cb308c108d8297a7942%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304954009395447&sdata=ZGxOLgELWZPU1NWfqHiJmZuaFBIw6brat7QwVx8sEAc%3D&reserved=0>

On Wed, Jul 15, 2020, at 10:22 PM, Daniel Buchner wrote:
> Wow, if that's the case, it's super unfortunate, because they can do
> literally every other type/value evaluation with JSON Schema. Have they
> consider working to add a stringified numeric type to JSON Schema?
> Seems like such a good opportunity to add value to an existing thing
> that does 90% of what they want.
>
> - Daniel
>
> -----Original Message-----
> From: Wayne Chang <wyc@fastmail.fm<mailto:wyc@fastmail.fm>>
> Sent: Wednesday, July 15, 2020 7:04 PM
> To: Daniel Buchner <Daniel.Buchner@microsoft.com<mailto:Daniel.Buchner@microsoft.com>>; Kristina Yasuda
> <Kristina.Yasuda@microsoft.com<mailto:Kristina.Yasuda@microsoft.com>>; W3C Credentials CG
> <public-credentials@w3.org<mailto:public-credentials@w3.org>>; Brent Zundel <brent.zundel@evernym.com<mailto:brent.zundel@evernym.com>>;
> Dave Longley <dlongley@digitalbazaar.com<mailto:dlongley@digitalbazaar.com>>; Tobias Looker
> <tobias.looker@mattr.global<mailto:tobias.looker@mattr.global>>
> Subject: Re: [EXTERNAL] Re: "Derivative predicate" of W3C VC WG and
> "Expression Language" of OIDF ekyc-ida WG
>
> Hey Dan, just some initial thoughts here after a brief review of the spec.
>
> In the following example, it seems that the spec allows for certain
> semantic/industry-specific comparison using the "gt" operator on
> strings, which would be not possible in JSON Schema:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgruposantander.github.io%2Fdigital-trust-docs%2Fassertions%2Fclaim-assertions-00.html%23name-example&amp;data=02%7C01%7CKristina.Yasuda%40microsoft.com%7Cf4fcb1e315dc442a258808d8293a6aeb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304678180868210&amp;sdata=20dNlGdQOW6OPIOuCfC8jOOLgJnEjH4fcZkBdBOVmw4%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgruposantander.github.io%2Fdigital-trust-docs%2Fassertions%2Fclaim-assertions-00.html%23name-example&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cc928520695404cb308c108d8297a7942%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304954009405443&sdata=daBD11k7s7YLIjatmDKDS5RYB%2F3VyZ6jYL1RPWdCuZM%3D&reserved=0>
>
> It's pretty common in the financial sector to represent currencies as
> strings as prevent unintentional IEEE 754 mantissa-bending from getting
> settlements wrong and sending everyone to jail. There is also a
> capabilities negotiation section with
> "assertion_claims_query_language_supported" that may benefit from
> universal identifiers like
> "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fschema.bigbankstandards.com%2Foperators%2Fgt&amp;data=02%7C01%7CKristina.Yasuda%40microsoft.com%7Cf4fcb1e315dc442a258808d8293a6aeb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304678180868210&amp;sdata=ECb4KnJl%2Bf1Ci9t%2B8d45mZsNDv%2BeKK%2FQzPxssEWBUIc%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fschema.bigbankstandards.com%2Foperators%2Fgt&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cc928520695404cb308c108d8297a7942%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304954009415438&sdata=DGki9uk9umRTvb5vKeWNLv%2FWc5rSXIg0BLowLe8WU2o%3D&reserved=0>". These semantics might be different enough to target a goal other than recreating JSON Schema.
>
>
>
> On Wed, Jul 15, 2020, at 9:53 PM, Daniel Buchner wrote:
> > I guess my first question would be: why are the folks who created this Open ID proposal trying to recreate JSON Schema, when we already have JSON Schema?
>
> >
>
>
> > *From:* Wayne Chang <wyc@fastmail.fm<mailto:wyc@fastmail.fm>>
> > *Sent:* Wednesday, July 15, 2020 6:05 PM
> > *To:* Kristina Yasuda <Kristina.Yasuda@microsoft.com<mailto:Kristina.Yasuda@microsoft.com>>; W3C Credentials
> > CG <public-credentials@w3.org<mailto:public-credentials@w3.org>>; Brent Zundel
> > <brent.zundel@evernym.com<mailto:brent.zundel@evernym.com>>; Daniel Buchner
> > <Daniel.Buchner@microsoft.com<mailto:Daniel.Buchner@microsoft.com>>; Dave Longley
> > <dlongley@digitalbazaar.com<mailto:dlongley@digitalbazaar.com>>; Tobias Looker
> > <tobias.looker@mattr.global<mailto:tobias.looker@mattr.global>>
> > *Subject:* [EXTERNAL] Re: "Derivative predicate" of W3C VC WG and
> > "Expression Language" of OIDF ekyc-ida WG
>
> >
>
> > Thanks for your message, Kristina! Directly adding Brent + Dan + Dave + Tobias here, whom I believe have been working on related efforts in this problem space across Aries, DIF, and CCG. I hope there's an opportunity consolidate efforts.
>
> >
>
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c-

> > ccg.github.io%2Fvp-request-spec%2F&amp;data=02%7C01%7CDaniel.Buchner%4
> > 0microsoft.com%7C8856a60f31f142f0399508d8292c9f9c%7C72f988bf86f141af91
> > ab2d7cd011db47%7C1%7C0%7C637304618921838596&amp;sdata=64kakuLf5f3F%2Bo
> > L39cjYY05nIRZZGN8dOHuBZXNPWGU%3D&amp;reserved=0
> > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c

<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c%0b>> > -ccg.github.io%2Fvp-request-spec%2F&amp;data=02%7C01%7CDaniel.Buchner%
> > 40microsoft.com%7C8856a60f31f142f0399508d8292c9f9c%7C72f988bf86f141af9
> > 1ab2d7cd011db47%7C1%7C0%7C637304618921838596&amp;sdata=64kakuLf5f3F%2B
> > oL39cjYY05nIRZZGN8dOHuBZXNPWGU%3D&amp;reserved=0>
>
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fiden

> > tity.foundation%2Fpresentation-exchange%2F&amp;data=02%7C01%7CDaniel.B
> > uchner%40microsoft.com%7C8856a60f31f142f0399508d8292c9f9c%7C72f988bf86
> > f141af91ab2d7cd011db47%7C1%7C0%7C637304618921848592&amp;sdata=wAVCy3Nd
> > VrdTBykEW373ATo%2FxOj2sUs1FdarG7QJlws%3D&amp;reserved=0
> > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fide

<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fide%0b>> > ntity.foundation%2Fpresentation-exchange%2F&amp;data=02%7C01%7CDaniel.
> > Buchner%40microsoft.com%7C8856a60f31f142f0399508d8292c9f9c%7C72f988bf8
> > 6f141af91ab2d7cd011db47%7C1%7C0%7C637304618921848592&amp;sdata=wAVCy3N
> > dVrdTBykEW373ATo%2FxOj2sUs1FdarG7QJlws%3D&amp;reserved=0>
>
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmatt

> > rglobal.github.io%2Foidc-client-bound-assertions-spec%2F&amp;data=02%7
> > C01%7CDaniel.Buchner%40microsoft.com%7C8856a60f31f142f0399508d8292c9f9
> > c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304618921848592&amp;
> > sdata=UGG%2Fw4IWYH7oieOqoMV9G9Moj0QYv0QYxE24SAXKdBg%3D&amp;reserved=0
> > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmat

<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmat%0b>> > trglobal.github.io%2Foidc-client-bound-assertions-spec%2F&amp;data=02%
> > 7C01%7CDaniel.Buchner%40microsoft.com%7C8856a60f31f142f0399508d8292c9f
> > 9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304618921848592&amp
> > ;sdata=UGG%2Fw4IWYH7oieOqoMV9G9Moj0QYv0QYxE24SAXKdBg%3D&amp;reserved=0
> > >
>
> >
>
> > Best,
>
> > - Wayne
>
> >
>
> > On Wed, Jul 15, 2020, at 7:58 PM, Kristina Yasuda wrote:
>
> >> Hi,
>
> >>
>
> >> I am reaching out since there seems to be synergy with 'derived predicate' concept <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fvc-data-model%2F%23dfn-predicates&amp;data=02%7C01%7CKristina.Yasuda%40microsoft.com%7Cf4fcb1e315dc442a258808d8293a6aeb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304678180868210&amp;sdata=nZVai%2Fi6Wuo4HGs16Tkd3kCWds%2BEKk0ABUS5WXahJoo%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fvc-data-model%2F%23dfn-predicates&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cc928520695404cb308c108d8297a7942%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304954009425433&sdata=%2B6KH4Zsdvn02kRhXev3q2LilAFtkzX5Y%2FU1y9v786FA%3D&reserved=0>> of W3C VC spec and  expression language <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgruposantander.github.io%2Fdigital-trust-docs%2Fassertions%2Fclaim-assertions-00.html%23name-expression-language&amp;data=02%7C01%7CKristina.Yasuda%40microsoft.com%7Cf4fcb1e315dc442a258808d8293a6aeb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304678180868210&amp;sdata=Yvp6zn%2BmURxHU7V%2FHn8zWf9kubReS16kCbnAu9MjMok%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgruposantander.github.io%2Fdigital-trust-docs%2Fassertions%2Fclaim-assertions-00.html%23name-expression-language&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cc928520695404cb308c108d8297a7942%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304954009425433&sdata=bP1HMENGIuEwrkt379MAqgStIKbnq8NlWP0w3LXoz7Y%3D&reserved=0>> concept being discussed in OpenID Foundation(OIDF)'s  ekyc-ida (identity assurance) WG <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fwg%2Fekyc-ida%2F&amp;data=02%7C01%7CKristina.Yasuda%40microsoft.com%7Cf4fcb1e315dc442a258808d8293a6aeb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304678180868210&amp;sdata=FVBjsdspaVTfHfecJXDvTlsE%2FVFKESQpC4VYM1I4wcQ%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fwg%2Fekyc-ida%2F&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cc928520695404cb308c108d8297a7942%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304954009435430&sdata=AOXH%2BWiN7WhjXMqpJCL0EAJq4Y9RfL4t8PDJ%2ByyH5VM%3D&reserved=0>>  in the context of selective disclosure.
>
> >>
>
> >> This part
> >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3

<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3%0b>> >> c.github.io%2Fvc-imp-guide%2F%23predicates&amp;data=02%7C01%7CDaniel.
> >> Buchner%40microsoft.com%7C8856a60f31f142f0399508d8292c9f9c%7C72f988bf
> >> 86f141af91ab2d7cd011db47%7C1%7C0%7C637304618921848592&amp;sdata=Qtt8u
> >> tmjeG2PJgr8VVjhU094KQppi7eS7ZgvgcgIHQ8%3D&amp;reserved=0> in the
> >> vc-imp-guide is the most detailed implementation of derived predicate
> >> that I have seen. Do you know if
>
> >>  * there is more specific proposal for how to express the derived
> >> predicates
> >>  * there is anyone actually implementing this feature OIDF is
> >> discussing the concept of  expression language <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgruposantander.github.io%2Fdigital-trust-docs%2Fassertions%2Fclaim-assertions-00.html%23name-expression-language&amp;data=02%7C01%7CKristina.Yasuda%40microsoft.com%7Cf4fcb1e315dc442a258808d8293a6aeb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304678180868210&amp;sdata=Yvp6zn%2BmURxHU7V%2FHn8zWf9kubReS16kCbnAu9MjMok%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgruposantander.github.io%2Fdigital-trust-docs%2Fassertions%2Fclaim-assertions-00.html%23name-expression-language&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cc928520695404cb308c108d8297a7942%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304954009445425&sdata=UjcBtZ1R9vzp1iD1tJKVt0AeJlzS8TG8DPZO4JiYZcc%3D&reserved=0>> which could be more generic than "ageOver18" property in VC imp-guide and ekyc-ida wg has been wondering if we could work together on this important topic.
>
> >> OIDF's current proposal is outlined here <https://gruposantander.github..io/digital-trust-docs/assertions/claim-assertions-00.html>. For example for the alcohol purchase age, in the US it is ageOver18, but in Japan it is ageOver20. The concept of expression language would allow to express this as {"age" : { "gt" : "18", "lt" : "20" } } where gt is 'greater than' and 'lt' is less than..
>
> >>
>
> >> Best,
>
> >> Kristina
>
> >> *Identity Standards Team, Microsoft Corp.*
>
> >>
>
> >>
>
> >>
>
> >
>
Emails aren't always secure, and they may be intercepted or changed after they've been sent. Santander doesn't accept liability if this happens. If you think someone may have interfered with this email, please get in touch with the sender another way. This message doesn't create or change any contract. Santander doesn't accept responsibility for damage caused by any viruses contained in this email or its attachments. Emails may be monitored. If you've received this email by mistake, please let the sender know at once that it's gone to the wrong person and then destroy it without copying, using, or telling anyone about its contents.

Santander UK plc. Registered Office: 2 Triton Square, Regent's Place, London, NW1 3AN, United Kingdom. Registered Number 2294747. Registered in England and Wales. https://www.santander.co.uk. Telephone 0800 389 7000. Calls may be recorded or monitored. Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Our Financial Services Register number is 106054. You can check this on the Financial Services Register by visiting the FCA’s website https://www.fca.org.uk/register. Santander and the flame logo are registered trademarks.


Ref:[PDB#1-4B]