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

One issue is JSON Schema/path are not a standard and we are trying not to introduce these kind of open dependencies in eKYC

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

Hi Daniel,

Thanks for taking the time to review this.

You are correct, the spec is high-level on purpose and we also specify that those simple operations are just a proposal and examples are not normative.
Given that specification is valid for somebody to extend OpenId in such a way, I believe it would make sense to clearly define what are the types and operations you want to support. It would also make sense to agree that same definition with a wider group of organizations operating under the same marketplace or trust framework.

Anyway, by providing OP Metadata using the Discovery endpoint, consumers/RPs will at least understand the available capabilities.

Hope this helps
Alberto

From: Daniel Buchner <Daniel.Buchner@microsoft.com<mailto:Daniel.Buchner@microsoft.com>>
Date: Thursday, 16 July 2020 at 15:20
To: Alberto Pulido Moyano <alberto.pulido@santander.co.uk<mailto:alberto.pulido@santander.co.uk>>, Kristina Yasuda <Kristina.Yasuda@microsoft.com<mailto:Kristina.Yasuda@microsoft.com>>, Wayne Chang <wyc@fastmail.fm<mailto:wyc@fastmail.fm>>, 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: #External Sender# RE: Re: [EXTERNAL] Re: "Derivative predicate" of W3C VC WG and "Expression Language" of OIDF ekyc-ida WG

I am trying to better understand this part of your response: “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” – are you saying the spec itself does not define normative rules for specific types and the processing steps involved in parsing/evaluating their values? For instance, someone cited that the spec shows examples of string-based two-place decimal values being compared for monetary purposes, which I would think implies a series of steps where you would have to cast the strings to numeric values and perform math operations to validate, but I didn’t see any definition of those types, or the processing rules that define how to evaluate them, in the body of the draft. Am I correct in thinking this spec is codifying high-level expression properties (eq, gt, lt, etc.), with type and processing rule definition/evaluation being left to userspace?

- Daniel

From: Pulido Moyano, Alberto <alberto.pulido@santander.co.uk<mailto:alberto.pulido@santander.co.uk>>
Sent: Thursday, July 16, 2020 3:45 AM
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: 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%7Ctonynad%40microsoft.com%7C2799165eb8844b2317a908d82999ab5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305087280535810&sdata=QtnrSo4yQdXBOBvnvlkhBTCCItt4H1eYgBu0OQ9Ru20%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@01D65B59.3FF499A0]
[cid:image002.png@01D65B59.3FF499A0]
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%7Ctonynad%40microsoft.com%7C2799165eb8844b2317a908d82999ab5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305087280545802&sdata=y5%2BwG01aqWHEY26F5MPE6K0sxjMUcu0VYm8Hryl0xT4%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%7Ctonynad%40microsoft.com%7C2799165eb8844b2317a908d82999ab5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305087280545802&sdata=YmLTI5VOPsceVMRkagAhBxNUB2G3lUbCidQTkGVjYS4%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%7Ctonynad%40microsoft.com%7C2799165eb8844b2317a908d82999ab5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305087280555803&sdata=6dYj%2B4vxCROcbMQANm0lGeSv01ck9dGpfVtBI57sbf8%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%7Ctonynad%40microsoft.com%7C2799165eb8844b2317a908d82999ab5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305087280555803&sdata=hMN4RAwfvZbSMrMtPyJdvyWCawk0E5RpcQmYCnPv1U8%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%7Ctonynad%40microsoft.com%7C2799165eb8844b2317a908d82999ab5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305087280565793&sdata=Z9eybPLAFdu2YBuulXJXW8PcX%2BKs1nqM4ImU4E4pG0E%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%7Ctonynad%40microsoft.com%7C2799165eb8844b2317a908d82999ab5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305087280565793&sdata=z1HpCKtUeQPNY%2BaYiTNFDn1uS2dzXDUywX%2BmR3oL8%2F4%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%7Ctonynad%40microsoft.com%7C2799165eb8844b2317a908d82999ab5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305087280575783&sdata=lDk1Al%2BmygHH4svg%2By2rrwSoO1lTkjeWk3MGY4UVzhA%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%7Ctonynad%40microsoft.com%7C2799165eb8844b2317a908d82999ab5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305087280575783&sdata=RJAZuvGKP6nba0NFpO8UeVx%2BpoH7TCMovO2MamM3Vbs%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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.santander.co.uk%2F&data=02%7C01%7Ctonynad%40microsoft.com%7C2799165eb8844b2317a908d82999ab5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305087280585780&sdata=641CiBrXhOrJN4fCDu7tUh4GMyaUclRYZARTFdl87M0%3D&reserved=0>. 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fca.org.uk%2Fregister&data=02%7C01%7Ctonynad%40microsoft.com%7C2799165eb8844b2317a908d82999ab5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305087280585780&sdata=UldJ9lO9G3S%2FpmZ79AMIH95SaQxFAhdWGj3elc5J4hk%3D&reserved=0>. Santander and the flame logo are registered trademarks.


Ref:[PDB#1-4B]