Topics

DIF Interop Goal Setting


orie
 

Hey All,

We've had the same goal for a while now, but I'd like to try and downscope it a bit so we can make some progress.

We want to create a web application demo of Issuer, Holder, Verifier flow for an Ed Tech example using JWT VC and VP, and multiple DID Methods.

We've been stumped by wallet support / interop, so we are going to be sidestepping it.

I suggest we use CHAPI - https://github.com/decentralized-identity/interoperability/issues/24 

And build an all web stack demo, no native mobile app support for the first phase.

The reason is that interop around native mobile application development is a bit stalled for a couple reasons:

1. Hubs / EDV are not well defined (mobile apps can't just shirk responsibility to them).
2. DIDComm not in DIF / not standardized (No common language for JWE / QR Code flows... also not clear if a Hub/Agent would still be required)
3. QR Codes all handled differently... while many native apps use them, there is no standard for using them
4. OIDC SIOP code not available MS / Evernym have demo'ed it at IIW, but the code is not ready for public / open source use.

Here is a demo of getting a credential in a web wallet using chapi: https://github.com/digitalbazaar/credential-handler-polyfill

The credential handler API is a CCG work item: https://w3c-ccg.github.io/credential-handler-api/

As such its much further along towards standardization than anything else. As is noted in the spec, it is possible to use CHAPI with mobile apps, I think it's more valuable to encourage mobile apps to implement a CHAPI interface than it is to ask them to guess at a standard for QR Code flows based on DIDComm / Agents / Hubs / EDV... after all, these concepts can be plugged into CHAPI at a later date.

Additionally an all web app demo is easier to achieve, javascript / html / css are the only things needed.

Looking forward to discussing further on upcoming calls.

OS



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



Kim Hamilton
 

Interesting, this would greatly simplify things. I'd also like to discuss


Oliver Terbu
 

I agree with 1) and 2) but disagree with 3) with 4).

IMO, we should focus on:
- verification of verifiable presentations using different DID methods
- providing a demo RP for SIOP --> I'm working on it and that should be ready by the end of this week.
- providing a demo browser-based Identity Wallet for SIOP (no credentials, just DID AuthN), e.g., using electron --> TODO: need some volunteer?
- verification of verifiable presentations using different DID methods
- extending SIOP to exchange credentials  --> by basically adding two paragraphs to the current SIOP spec and modifying the demo apps mentioned above.

The SIOP spec is already in a state that can be implemented. There is only one issue around encryption / JWE missing but this won't prevent us from trying this out in the course of the interop project. 

@Orie: After that we can focus on how we could use CHAPI. Correct if I am wrong but CHAPI supposed to become a W3C standard that will be implemented by browser vendors. The current implementation is a polyfill / JS library. My concern is that in reality this entails that CHAPI will be a feature of the browser itself and our community won't have control over how "get" and "store" will be implemented by these browser vendors eventually. It does not answer the question how these functions communicate with a DID Comm agent or identity hub. Is this observation correct?

Oliver


On Wed, Nov 13, 2019 at 12:16 AM orie <orie@...> wrote:
Hey All,

We've had the same goal for a while now, but I'd like to try and downscope it a bit so we can make some progress.

We want to create a web application demo of Issuer, Holder, Verifier flow for an Ed Tech example using JWT VC and VP, and multiple DID Methods.

We've been stumped by wallet support / interop, so we are going to be sidestepping it.

I suggest we use CHAPI - https://github.com/decentralized-identity/interoperability/issues/24 

And build an all web stack demo, no native mobile app support for the first phase.

The reason is that interop around native mobile application development is a bit stalled for a couple reasons:

1. Hubs / EDV are not well defined (mobile apps can't just shirk responsibility to them).
2. DIDComm not in DIF / not standardized (No common language for JWE / QR Code flows... also not clear if a Hub/Agent would still be required)
3. QR Codes all handled differently... while many native apps use them, there is no standard for using them
4. OIDC SIOP code not available MS / Evernym have demo'ed it at IIW, but the code is not ready for public / open source use.

Here is a demo of getting a credential in a web wallet using chapi: https://github.com/digitalbazaar/credential-handler-polyfill

The credential handler API is a CCG work item: https://w3c-ccg.github.io/credential-handler-api/

As such its much further along towards standardization than anything else. As is noted in the spec, it is possible to use CHAPI with mobile apps, I think it's more valuable to encourage mobile apps to implement a CHAPI interface than it is to ask them to guess at a standard for QR Code flows based on DIDComm / Agents / Hubs / EDV... after all, these concepts can be plugged into CHAPI at a later date.

Additionally an all web app demo is easier to achieve, javascript / html / css are the only things needed.

Looking forward to discussing further on upcoming calls.

OS



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



orie
 

I'm excited to see the SIOP work!

It's true that CHAPI is meant to be implemented by browsers, since mobile phones all have browsers, this issue of:

"I'm on a website, and I want to get a credential into my mobile phone wallet..." is not going to go away.

The specifics around how to accomplish this with the current polyfill need to be worked out. 

I'm trying to drive interop at DIF to consider technologies using the following criteria:

1. Is there a spec maintained by an SDO (with IPR protection).
2. Is there an implementation / demo.

CHAPI meets these 2 criteria for browsers only.

OIDC SIOP meets one of them (hopefully both soon).

DIDComm meets none of them (hopefully this will change soon).

I'm fully in support of switching gears to primarily focus on SIOP/DIDComm for interop if things change, but I want to drive the solution that is furthest along / closest to satisfying requirements to be completed, and currently that appears to be CHAPI.

OS





On Mon, Nov 25, 2019 at 9:50 AM Oliver Terbu <oliver.terbu@...> wrote:
I agree with 1) and 2) but disagree with 3) with 4).

IMO, we should focus on:
- verification of verifiable presentations using different DID methods
- providing a demo RP for SIOP --> I'm working on it and that should be ready by the end of this week.
- providing a demo browser-based Identity Wallet for SIOP (no credentials, just DID AuthN), e.g., using electron --> TODO: need some volunteer?
- verification of verifiable presentations using different DID methods
- extending SIOP to exchange credentials  --> by basically adding two paragraphs to the current SIOP spec and modifying the demo apps mentioned above.

The SIOP spec is already in a state that can be implemented. There is only one issue around encryption / JWE missing but this won't prevent us from trying this out in the course of the interop project. 

@Orie: After that we can focus on how we could use CHAPI. Correct if I am wrong but CHAPI supposed to become a W3C standard that will be implemented by browser vendors. The current implementation is a polyfill / JS library. My concern is that in reality this entails that CHAPI will be a feature of the browser itself and our community won't have control over how "get" and "store" will be implemented by these browser vendors eventually. It does not answer the question how these functions communicate with a DID Comm agent or identity hub. Is this observation correct?

Oliver

On Wed, Nov 13, 2019 at 12:16 AM orie <orie@...> wrote:
Hey All,

We've had the same goal for a while now, but I'd like to try and downscope it a bit so we can make some progress.

We want to create a web application demo of Issuer, Holder, Verifier flow for an Ed Tech example using JWT VC and VP, and multiple DID Methods.

We've been stumped by wallet support / interop, so we are going to be sidestepping it.

I suggest we use CHAPI - https://github.com/decentralized-identity/interoperability/issues/24 

And build an all web stack demo, no native mobile app support for the first phase.

The reason is that interop around native mobile application development is a bit stalled for a couple reasons:

1. Hubs / EDV are not well defined (mobile apps can't just shirk responsibility to them).
2. DIDComm not in DIF / not standardized (No common language for JWE / QR Code flows... also not clear if a Hub/Agent would still be required)
3. QR Codes all handled differently... while many native apps use them, there is no standard for using them
4. OIDC SIOP code not available MS / Evernym have demo'ed it at IIW, but the code is not ready for public / open source use.

Here is a demo of getting a credential in a web wallet using chapi: https://github.com/digitalbazaar/credential-handler-polyfill

The credential handler API is a CCG work item: https://w3c-ccg.github.io/credential-handler-api/

As such its much further along towards standardization than anything else. As is noted in the spec, it is possible to use CHAPI with mobile apps, I think it's more valuable to encourage mobile apps to implement a CHAPI interface than it is to ask them to guess at a standard for QR Code flows based on DIDComm / Agents / Hubs / EDV... after all, these concepts can be plugged into CHAPI at a later date.

Additionally an all web app demo is easier to achieve, javascript / html / css are the only things needed.

Looking forward to discussing further on upcoming calls.

OS



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




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