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

I'd love to see something that did not mix Transport, Data Model, and Data
Selection concerns all into 1 spec... not saying anyone is doing this, it's
just a concern.

DIF is trying our best to tackle just Data Selection here:
https://github.com/decentralized-identity/presentation-exchange
W3C CCG has a request specification that works with a browser polyfill
here:
https://w3c-ccg.github.io/vp-request-spec/#example-5-a-zcap-request-query
Mattr has this OIDC proposal for client bound assertions here:
https://mattrglobal.github.io/oidc-client-bound-assertions-spec/

The problem is that legacy systems have formats that are not supported well
by some of the new specs... for example, the support for JWT in VC Data
Model is poor, and without the support from well known open id
configuration / other OIDF tweaks that make OIDC work... VC JWT as a format
is poorly documented and hard to use by itself... (JOSE/OIDC are fine, I am
not talking about them here). This leads to a dependency on existing
software solutions for moving JWTs around, and some real trouble with
working with decentralized identifiers.

Regardless of the "Credential / Claim / CryptoAssertion" format... we all
need to transport them from A to B, and that means we all need a way of B
describing to A what a "well formed request" should look like, and A needs
construct that request in a way that B can understand.

If your transport only supports 1 of the 3+ assertions formats out there...
you are obviously not going to receive credentials from people who don't
use that format.

That's why the Presentation Exchange spec is so hard... we are trying to
solve the problem:

Create a verifiable presentation of the credentials needed to open a bank
account... without telling people which credential format or transports
they MUST use....

Which obviously means, as a spec, it MUST work for all formats and
transports :)

OS


On Thu, Jul 16, 2020 at 12:12 PM Anthony Nadalin <tonynad@microsoft.com>
wrote:

> 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>
> *Date: *Thursday, 16 July 2020 at 15:20
> *To: *Alberto Pulido Moyano <alberto.pulido@santander.co.uk>, 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: *#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>
> *Sent:* Thursday, July 16, 2020 3:45 AM
> *To:* 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>; 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: [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
>
>
>
> *Alberto Pulido*
>
> Technical Expert
>
> Innovation Hub
>
> +44 (0)7710 380 464
>
> Milton Keynes, UK
>
>
>
>
>
>
>
> *From: *Kristina Yasuda <Kristina.Yasuda@microsoft.com>
> *Date: *Thursday, 16 July 2020 at 09:56
> *To: *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>, Alberto Pulido Moyano <
> 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>
> *送信日時**:* 2020年7月16日 12:43
> *宛先**:* Daniel Buchner <Daniel.Buchner@microsoft.com>; Kristina Yasuda <
> Kristina.Yasuda@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>
> *件名**:* 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>
> > Sent: Wednesday, July 15, 2020 7:04 PM
> > To: Daniel Buchner <Daniel.Buchner@microsoft.com>; Kristina Yasuda
> > <Kristina.Yasuda@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>
> > 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>
> > > *Sent:* Wednesday, July 15, 2020 6:05 PM
> > > *To:* Kristina Yasuda <Kristina.Yasuda@microsoft.com>; W3C
> Credentials
> > > CG <public-credentials@w3.org>; Brent Zundel
> > > <brent.zundel@evernym.com>; Daniel Buchner
> > > <Daniel.Buchner@microsoft.com>; Dave Longley
> > > <dlongley@digitalbazaar.com>; Tobias Looker
> > > <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]
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>