Date   

Re: Interoperability WG - next steps

Sam Chase <samantha@...>
 

Is 6AM PST the conformed ongoing meeting time?

On Jul 17, 2020, at 9:06 AM, Balázs Némethi <balazs@...> wrote:



Dear all,

Thanks to everyone who participated in the Interoperability WG meeting on Wednesday. We covered a lot of ground and there has been a huge interest.
For those who could not make it, links to the recordings can be found in the meeting notes here

Action items for the group:

  1. Please comment on the draft WG charter before the start of the next meeting so we can do a final round of "issue review"/live editing next week.
  2. Nominate Chairs and/or Liaisons (community representatives, role description in the WG charter) by 29th July when we will start a one-week voting process.
  3. Start to list potential work items for the Interop WG
  4. Join the mailing list to simplify communication (all future communications will take place there)
If you have any questions or concerns, please reach out to me or Juan. 

Please circulate this email within your communities.

Best regards,

--

Balázs Némethi
Operations @ DIF


Interoperability WG - next steps

Balázs Némethi
 

Dear all,

Thanks to everyone who participated in the Interoperability WG meeting on Wednesday. We covered a lot of ground and there has been a huge interest.
For those who could not make it, links to the recordings can be found in the meeting notes here

Action items for the group:

  1. Please comment on the draft WG charter before the start of the next meeting so we can do a final round of "issue review"/live editing next week.
  2. Nominate Chairs and/or Liaisons (community representatives, role description in the WG charter) by 29th July when we will start a one-week voting process.
  3. Start to list potential work items for the Interop WG
  4. Join the mailing list to simplify communication (all future communications will take place there)
If you have any questions or concerns, please reach out to me or Juan. 

Please circulate this email within your communities.

Best regards,

--

Balázs Némethi
Operations @ DIF


Re: Interoperability WG - follow up and next steps

Juan Caballero
 

Thanks! No news is good news, because we haven't missed anything :D


On Mon, Jul 6, 2020 at 1:48 PM sankarshan <sankarshan@...> wrote:
There is no further progress around the outreach to ToIP on the topic of Interoperability Profile (https://wiki.trustoverip.org/pages/viewpage.action?pageId=66073) and synergy. Will keep the group posted.



--
-----------------
Juan Caballero
Communications & Research Lead, Spherity.com
Next Meetup: 18/6 https://spherity_open_office2.eventbrite.com/

Berlin-based: +49 1573 5994525
Signal/whatsapp: +1 415-3101351


Re: Interoperability WG - follow up and next steps

Joachim Lohkamp
 

Thank you Sam for sharing this. Looking at the links you provided this group at W3C is obviously representing a small subset of interop efforts within W3C (namely around Solid) but definetly there is a whole bunch of communities building different technologies for Web2/Web3, many of them working towards interoperability with others.

The DIF effort as I understand goes towards bringing as many, ideally all, of these communities together to discuss and hopefully align on interop efforts and pathways.

Best, Joachim

Joachim Lohkamp
Founder & CEO
+49 176 7697 0369
jolocom.io info@... Our events
Twitter Telegram GitHub YouTube Medium
Waldemarstr. 37A, 10999 Berlin, Germany
CEO (Geschäftsführer): Joachim Lokhamp
Amtsgericht Charlottenburg (Berlin): HRB 158758 B

On Jul 2, 2020, at 5:37 PM, Sam Mathews Chase <samantha@...> wrote:

Hi all,

I sat in on the Solid weekly call this morning to invite the community to our interop group, it seems there is already an interop panel at W3C.

I am deeply concerned that we are making another group and must urge us all to consider joining the existing interop group with Solid rather than make an entirely new group. How can we best join our efforts?

I'm joining the Solid group, it makes the most sense to join is the one that is already functioning.





On Mon, Jun 29, 2020 at 12:25 AM Balázs Némethi <balazs@...> wrote:
Dear all,

Thank you for the call last week! 

To find the time that fits the most people, I would like to invite all of you to fill out this doodle poll. We will have two meeting times to create a group available for all time zones, fill out accordingly.
https://doodle.com/poll/9er4f5g5qwygqnse#calendar  <- we aim to schedule the first meeting for the week starting on the 6th July

I want to ask everyone as well as the (interim) liaisons to circle the doodle and the mailing list https://dif.groups.io/g/interop-wg within their communities. Thank you! 

Let's make Interop happen!

Best,


On Fri, Jun 26, 2020 at 8:27 PM Balázs Némethi <balazs@...> wrote:
Dear all,


Thank you for the Interop WG kick-off call! 
We are well into some of the admin work, we heard proposals and ideas on how the WG should start operations. The goal of the first meeting(s) is to agree on a path and the next steps to run a cross-community group the most effectively. 

We would ask you to share the mailing list with your communities so we can strengthen each other and make sure that the shared goal for interoperability becomes a reality. 

Next steps:

Please fill out this poll to find the time for the next WG setting meetings and sign up for the mailing list:

Decisions during the first meeting: 

Interim Chairs: 
Orie Steele and Balazs Nemethi volunteered for interop co-chair roles until we finalize the charter.

Interim community liaisons:
  • W3C CCG - Orie 
  • Solid/InRupt - Sam (Venn) 
  • MyData - Kristina 
  • ToIP - Ajay + Sankarshan  
  • HL Aries - Sam Curren 
Recording: zoom link


Thank you, 

-- 

Balázs Némethi
Operations @ DIF


-- 

Balázs Némethi
Operations @ DIF


Re: Interoperability WG - follow up and next steps

Sam Mathews Chase <samantha@...>
 

Hi all,

I sat in on the Solid weekly call this morning to invite the community to our interop group, it seems there is already an interop panel at W3C.

I am deeply concerned that we are making another group and must urge us all to consider joining the existing interop group with Solid rather than make an entirely new group. How can we best join our efforts?

I'm joining the Solid group, it makes the most sense to join is the one that is already functioning.





On Mon, Jun 29, 2020 at 12:25 AM Balázs Némethi <balazs@...> wrote:
Dear all,

Thank you for the call last week! 

To find the time that fits the most people, I would like to invite all of you to fill out this doodle poll. We will have two meeting times to create a group available for all time zones, fill out accordingly.
https://doodle.com/poll/9er4f5g5qwygqnse#calendar  <- we aim to schedule the first meeting for the week starting on the 6th July

I want to ask everyone as well as the (interim) liaisons to circle the doodle and the mailing list https://dif.groups.io/g/interop-wg within their communities. Thank you! 

Let's make Interop happen!

Best,


On Fri, Jun 26, 2020 at 8:27 PM Balázs Némethi <balazs@...> wrote:
Dear all,


Thank you for the Interop WG kick-off call! 
We are well into some of the admin work, we heard proposals and ideas on how the WG should start operations. The goal of the first meeting(s) is to agree on a path and the next steps to run a cross-community group the most effectively. 

We would ask you to share the mailing list with your communities so we can strengthen each other and make sure that the shared goal for interoperability becomes a reality. 

Next steps:

Please fill out this poll to find the time for the next WG setting meetings and sign up for the mailing list:

Decisions during the first meeting: 

Interim Chairs: 
Orie Steele and Balazs Nemethi volunteered for interop co-chair roles until we finalize the charter.

Interim community liaisons:
  • W3C CCG - Orie 
  • Solid/InRupt - Sam (Venn) 
  • MyData - Kristina 
  • ToIP - Ajay + Sankarshan  
  • HL Aries - Sam Curren 
Recording: zoom link


Thank you, 

--

Balázs Némethi
Operations @ DIF


--

Balázs Némethi
Operations @ DIF


Re: Interoperability WG - follow up and next steps

sankarshan
 

There is no further progress around the outreach to ToIP on the topic of Interoperability Profile (https://wiki.trustoverip.org/pages/viewpage.action?pageId=66073) and synergy. Will keep the group posted.


Re: Interoperability WG - follow up and next steps

Balázs Némethi
 

Dear all,

Thank you for the call last week! 

To find the time that fits the most people, I would like to invite all of you to fill out this doodle poll. We will have two meeting times to create a group available for all time zones, fill out accordingly.
https://doodle.com/poll/9er4f5g5qwygqnse#calendar  <- we aim to schedule the first meeting for the week starting on the 6th July

I want to ask everyone as well as the (interim) liaisons to circle the doodle and the mailing list https://dif.groups.io/g/interop-wg within their communities. Thank you! 

Let's make Interop happen!

Best,


On Fri, Jun 26, 2020 at 8:27 PM Balázs Némethi <balazs@...> wrote:
Dear all,


Thank you for the Interop WG kick-off call! 
We are well into some of the admin work, we heard proposals and ideas on how the WG should start operations. The goal of the first meeting(s) is to agree on a path and the next steps to run a cross-community group the most effectively. 

We would ask you to share the mailing list with your communities so we can strengthen each other and make sure that the shared goal for interoperability becomes a reality. 

Next steps:

Please fill out this poll to find the time for the next WG setting meetings and sign up for the mailing list:

Decisions during the first meeting: 

Interim Chairs: 
Orie Steele and Balazs Nemethi volunteered for interop co-chair roles until we finalize the charter.

Interim community liaisons:
  • W3C CCG - Orie 
  • Solid/InRupt - Sam (Venn) 
  • MyData - Kristina 
  • ToIP - Ajay + Sankarshan  
  • HL Aries - Sam Curren 
Recording: zoom link


Thank you, 

--

Balázs Némethi
Operations @ DIF


--

Balázs Némethi
Operations @ DIF


Interop WG - restart!

Balázs Némethi
 

  Dear all,


Today we restarted the Interop WG!! 
We are well into some of the admin work, we heard proposals and ideas on how the WG should start operations. The goal of the first meeting(s) is to agree on a path and the next steps to run a cross-community group the most effectively. 

The goal of this new (now) Working Group is to create a cross-community collaboration and project management on Interoperability. The draft scope is here: https://identity.foundation/interop/   

We would ask you to share the mailing list with your communities so we can strengthen each other and make sure that the shared goal for interoperability becomes a reality. 

Next steps:

Please fill out this poll to find the time for the next WG setting meetings and sign up for the mailing list:

Decisions during the first meeting: 

Interim Chairs: 
Orie Steele and Balazs Nemethi volunteered for interop co-chair roles until we finalize the charter.

Interim community liaisons:
  • W3C CCG - Orie 
  • Solid/InRupt - Sam (Venn) 
  • MyData - Kristina 
  • ToIP - Ajay + Sankarshan  
  • HL Aries - Sam Curren 
Recording: zoom link


Thank you, 


--

Balázs Némethi
Operations @ DIF


Help build OIDC SIOP

orie
 

DID Auth WG is looking for volunteers to help complete https://github.com/decentralized-identity/did-siop 

Please consider contributing.

OS

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



Re: DIF Interop Goal Setting

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



Re: DIF Interop Goal Setting

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



Re: DIF Interop Goal Setting

Kim Hamilton
 

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


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



Project Restructuring

orie
 

I have done some restructuring of the git repo for the interoperability project...  https://github.com/decentralized-identity/interoperability

My goal is to make room for more contributors, clarify what we can show technically, vs what we have adopted or "endorsed officially", and clarify what is needed to be "endorsed officially".

I've made these changes after various discussions in WGs and on slack, but feel free to raise an issue if you would like to challenge any of the decisions made.

There are a number of repo's under the DIF or elsewhere that could easily become endorsed by simply showing some small integration with the universal resolver.

In particular, I want to draw attention to:

https://github.com/decentralized-identity/interoperability/blob/master/docs/endorsements.md#verifiable-credentials-data-model

We've made some great progress over the last months, thanks all who have contributed to code or discussion.

I'm happy to answer questions over email or DIF slack (@OR13).

OS

--
ORIE STEELE
Chief Architect
www.transmute.industries



Simple Demo / DIDAuth Re: [InteropProject]

Rouven Heck
 

Thanks Christian! 


>The web service can issue a credential, verify a credential and verify a presentation. It uses btcr for the Issuer and either btcr or elements for the holder.

It would be great if we have 1-2 more teams building a different implementation and/or on a different DID method. 


> I still think we really need to demonstrate DID Auth, but do we really need DID Auth if we are using verifiable presentations?

It would be great if we could add this as well. 

@Oliver / Kyle - What do you think? Are we ready to implement a simple version already? 

> Sure I can get a verifiable credential for a given did, but won't the presentation be impossible to create unless I control signing keys linked to the verifiable credential subject/holder?

> What does it mean for me to present a membership credential issued to @Christian Lundkvist to the DIF verification service? Should that service only accept VPs that are signed by the subject of the VC the wrap?

These are good questions - I'm not sure to which extend these have already been discussed/agreed in specifications. Looking forward to the discussion. 

best,
Rouven


On Fri, Sep 13, 2019 at 09:26 Dominic Wörner <dom.woe@...> wrote:
Hi Orie,


AFAICT https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.md does regard a credential request as a DID Auth challenge. However, the credential request should have some unique information like a nonce that gets included in the verifiable presentation. Otherwise a man in the middle could re-use the signed presentation.

Best,
Dominic

Am Fr., 13. Sept. 2019 um 00:51 Uhr schrieb orie <orie@...>:
Awesome work!

One thing that occurred to me while updating the docs a while ago is this:

I still think we really need to demonstrate DID Auth, but do we really need DID Auth if we are using verifiable presentations?

Sure I can get a verifiable credential for a given did, but won't the presentation be impossible to create unless I control signing keys linked to the verifiable credential subject/holder?

I think the crux of this issue is that while verifying a JWS or JSON-LD Signature is a clearly defined process. Verifying a VC or VP is defined by:

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

What does it mean for me to present a membership credential issued to @Christian Lundkvist to the DIF verification service? Should that service only accept VPs that are signed by the subject of the VC the wrap?

Here the issue to track this: https://github.com/decentralized-identity/interop-project/issues/22

Please add your response to the github issue as well, for non mailing list members. 

OS



On Thu, Sep 12, 2019 at 3:58 PM Christian Lundkvist <christian.lundkvist@...> wrote:
Hi all, I created a PR which adds a server based interop demo. The web service can issue a credential, verify a credential and verify a presentation. It uses btcr for the Issuer and either btcr or elements for the holder.


Best,
Christian
On Sep 6, 2019, 11:31 -0400, orie <orie@...>, wrote:
This is probably more a topic for the VC working group, but I've been frustrated by this issue, IMO if an ethereum address is used to verify a signature, the JWS alg name should have ETH in it. Can you add some detail here?: https://github.com/w3c-dvcg/lds-ecdsa-secp256k1-2019/issues/1

I'm pretty sure that the uport did-jwt library supports both, ES256k and ES256K-R. From an interop perspective it seems a bit weird to be converting your public key to an ethereum address before trying to verify with a signature, but not if the signature alg makes it clear that you need to do that.

On Fri, Sep 6, 2019 at 11:08 AM Christian Lundkvist <christian.lundkvist@...> wrote:
> ES256K-R is not a requirement for using ETHR, however the default ETHR DIDs do not contain public keys, maybe thats what you mean?

Yep, that's what I meant! It's nice to be able to use the default ones.

Cheers,
Christian
On Sep 5, 2019, 18:29 -0400, Rouven Heck <rouven.heck@...>, wrote:
It would be great if we could find different teams/people to build the various 'entities' (obviously based on existing libraries/tools):

Is anyone interested to build:

A) the simple Issuer service (based on BTC-R?!)

B1 ) a CLI based holder 'wallet' based on DID method 2 
B2 ) a CLI based holder 'wallet' based on DID method 3 

C) a Verification service (checking the VCs from the issuer + the holder) - as per Christians flow)

If we could assign people/teams now to each of the entities we could coordinate more concretely on what needs to be spec'd and build before IIW. 

Cheers,
r


On Thu, Sep 5, 2019 at 5:48 PM orie <orie@...> wrote:
ES256K-R is not a requirement for using ETHR, however the default ETHR DIDs do not contain public keys, maybe thats what you mean?

We have adopted ES256K as the first JWS format for credentials, it requires a public key to verify.

As long as all DID Documents support publicKeyHex encoded secp256k1 keys, ES256K will work.

Feel free to add code / examples for ES256K-R, if you think its easier to show ETHR integration.

On Thu, Sep 5, 2019 at 4:22 PM Christian Lundkvist <christian.lundkvist@...> wrote:
Hi all, this is a sequence diagram for a very simple flow. The Issuer and Verifier would be automated services with an API, and the Holder would use a command line tool to call these services.

Ideally the Issuer would be a BTCR DID and the Holder would use a different DID method. If we choose say ethr here we would also need to support the ES256K-R algorithm (recoverable signatures) which would mean some more work.

Let me know what you think.




Cheers,
Christian
On Aug 30, 2019, 18:22 -0400, orie <orie@...>, wrote:
I added some sample code for a CLI demo: https://github.com/decentralized-identity/interop-project/issues/18

It lacks the DID Setup or Correct Credential Format, but has  working CLI demo using BTCR and JWS/JWT.

On Fri, Aug 30, 2019 at 4:54 PM Soma-Patel Anushka <asoma-patel@...> wrote:

Hi Rouven,

 

Thanks for including me in this.

 

I have shared this info with some members of the south African financial blockchain consortium to see if they are keen to participate.

 

I will let you know if there is any interest.

 

Regards,

Anushka

+27847547943

 

From: InteropProject@DIF.groups.io <InteropProject@DIF.groups.io> On Behalf Of Rouven Heck
Sent: 30 August 2019 03:25 PM
To: interopproject@dif.groups.io; Daniel Buchner <daniel.buchner@...>; Kyle Den Hartog <kyle.denhartog@...>; Joachim Lohkamp | Jolocom <joachim@...>; Kim Hamilton <kimdhamilton@...>; Carsten Stöcker <carsten.stoecker@...>
Subject: [InteropProject] InterOp Project - Status & next steps

 

This email originates from an external source. Stop and think before you click!


Dear all,

 

I would like to follow up around status & next steps around the InterOp work.

 

Next week is RWoT and in a month from now many of us will meet at IIW. It would be great if we could make a push towards a simple 'InterOp MVP'.

 

Orie already suggested a simple CLI based implementation (as MVP before using mobile wallets) which makes a lot of sense. There have been already some discussions last week in Slack, but I would like to make sure the broader community is included here hence the email follow up.

 

A few questions to kick off the discussion here:

 

1) Could we build a InterOp MVP based on the similar flow and actors like in our educational credential use-case? E.g. with the following setup:

    • one ISSUER to issue a credential (via command line rather than an educational website)
    • ideally, 2 different 'CLI Wallets' to receive, store and share the credential (based on different DID methods)
    • one VERIFIER to receive and validate the credential

If we do it all command-line based using existing libraries (?!) and split the work between at least 3-4 people/teams; we might be able to hack something together before IIW...  (maybe a little hackathon at RWoT, or the DIF F2F event before IIW)? 

 

I would expect that it would bring up some good questions which we could discuss at IIW (as well as start discussion the next phase with mobile wallets).

 

2) Any thoughts who could be the best candidates (teams) for the different parts given existing tools, demos or libraries? 

 

3) We currentky gave 7 open issues (https://github.com/decentralized-identity/interop-project/issues). Which ones are required to address for the simple 'InterOp MVP' demo?  Are we able to address these over the next week (given we have a few people at RWoT to discuss in person)?

 

Hope this makes sense? 

Looking forward to a good discussion here and some progress over the next 4 weeks!

 

Best,

Rouven

 


Old Mutual is a proudly Level 2 empowerment contributor company in terms of the Amended Financial Sector Generic Scorecard: Long-Term Assurers. .

Please access the link below to view our current BBBEE rating certificate. http://www.oldmutual.co.za/about-us/transformation/black-empowerment/bee-certificates.aspx

Please click on the following link to read the Old Mutual legal notice: http://www.oldmutual.co.za/about-us/governance/email-policy.aspx



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




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




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




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



Scope /[InteropProject] InterOp Project

Rouven Heck
 

Hi Dominic,

the InterOp project is about demonstrating interoperability between implementations. 

Implementing simple demos / PoCs across different clients/methods will allow us to discover outstanding questions and provides a 'proof' that interop is not just theoretically possible. 

The current phase is a first step to demo multiple DID methods to interact. Later we would like to extend this also to actual (mobile) wallets/agents (which is more powerful in demos for less technical people).

DIDAuth and DIDComm will be in scope for later phases. I suggest we discuss the next phases at the next DIF F2F meeting & IIW in October.

Best,
Rouven



On Fri, Sep 13, 2019 at 09:01 Dominic Wörner <dom.woe@...> wrote:
Good morning,

Christian, is this interop work only concerned with having common VC representations and interoperability between the DID methods?
I'm more concerned with the credential negotiation/communication protocols. Is the DIDcomm work from the Aries community the way to go?

Best, 
Dominic

Am Fr., 13. Sept. 2019 um 00:51 Uhr schrieb orie <orie@...>:
Awesome work!

One thing that occurred to me while updating the docs a while ago is this:

I still think we really need to demonstrate DID Auth, but do we really need DID Auth if we are using verifiable presentations?

Sure I can get a verifiable credential for a given did, but won't the presentation be impossible to create unless I control signing keys linked to the verifiable credential subject/holder?

I think the crux of this issue is that while verifying a JWS or JSON-LD Signature is a clearly defined process. Verifying a VC or VP is defined by:

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

What does it mean for me to present a membership credential issued to @Christian Lundkvist to the DIF verification service? Should that service only accept VPs that are signed by the subject of the VC the wrap?

Here the issue to track this: https://github.com/decentralized-identity/interop-project/issues/22

Please add your response to the github issue as well, for non mailing list members. 

OS



On Thu, Sep 12, 2019 at 3:58 PM Christian Lundkvist <christian.lundkvist@...> wrote:
Hi all, I created a PR which adds a server based interop demo. The web service can issue a credential, verify a credential and verify a presentation. It uses btcr for the Issuer and either btcr or elements for the holder.


Best,
Christian
On Sep 6, 2019, 11:31 -0400, orie <orie@...>, wrote:
This is probably more a topic for the VC working group, but I've been frustrated by this issue, IMO if an ethereum address is used to verify a signature, the JWS alg name should have ETH in it. Can you add some detail here?: https://github.com/w3c-dvcg/lds-ecdsa-secp256k1-2019/issues/1

I'm pretty sure that the uport did-jwt library supports both, ES256k and ES256K-R. From an interop perspective it seems a bit weird to be converting your public key to an ethereum address before trying to verify with a signature, but not if the signature alg makes it clear that you need to do that.

On Fri, Sep 6, 2019 at 11:08 AM Christian Lundkvist <christian.lundkvist@...> wrote:
> ES256K-R is not a requirement for using ETHR, however the default ETHR DIDs do not contain public keys, maybe thats what you mean?

Yep, that's what I meant! It's nice to be able to use the default ones.

Cheers,
Christian
On Sep 5, 2019, 18:29 -0400, Rouven Heck <rouven.heck@...>, wrote:
It would be great if we could find different teams/people to build the various 'entities' (obviously based on existing libraries/tools):

Is anyone interested to build:

A) the simple Issuer service (based on BTC-R?!)

B1 ) a CLI based holder 'wallet' based on DID method 2 
B2 ) a CLI based holder 'wallet' based on DID method 3 

C) a Verification service (checking the VCs from the issuer + the holder) - as per Christians flow)

If we could assign people/teams now to each of the entities we could coordinate more concretely on what needs to be spec'd and build before IIW. 

Cheers,
r


On Thu, Sep 5, 2019 at 5:48 PM orie <orie@...> wrote:
ES256K-R is not a requirement for using ETHR, however the default ETHR DIDs do not contain public keys, maybe thats what you mean?

We have adopted ES256K as the first JWS format for credentials, it requires a public key to verify.

As long as all DID Documents support publicKeyHex encoded secp256k1 keys, ES256K will work.

Feel free to add code / examples for ES256K-R, if you think its easier to show ETHR integration.

On Thu, Sep 5, 2019 at 4:22 PM Christian Lundkvist <christian.lundkvist@...> wrote:
Hi all, this is a sequence diagram for a very simple flow. The Issuer and Verifier would be automated services with an API, and the Holder would use a command line tool to call these services.

Ideally the Issuer would be a BTCR DID and the Holder would use a different DID method. If we choose say ethr here we would also need to support the ES256K-R algorithm (recoverable signatures) which would mean some more work.

Let me know what you think.




Cheers,
Christian
On Aug 30, 2019, 18:22 -0400, orie <orie@...>, wrote:
I added some sample code for a CLI demo: https://github.com/decentralized-identity/interop-project/issues/18

It lacks the DID Setup or Correct Credential Format, but has  working CLI demo using BTCR and JWS/JWT.

On Fri, Aug 30, 2019 at 4:54 PM Soma-Patel Anushka <asoma-patel@...> wrote:

Hi Rouven,

 

Thanks for including me in this.

 

I have shared this info with some members of the south African financial blockchain consortium to see if they are keen to participate.

 

I will let you know if there is any interest.

 

Regards,

Anushka

+27847547943

 

From: InteropProject@DIF.groups.io <InteropProject@DIF.groups.io> On Behalf Of Rouven Heck
Sent: 30 August 2019 03:25 PM
To: interopproject@dif.groups.io; Daniel Buchner <daniel.buchner@...>; Kyle Den Hartog <kyle.denhartog@...>; Joachim Lohkamp | Jolocom <joachim@...>; Kim Hamilton <kimdhamilton@...>; Carsten Stöcker <carsten.stoecker@...>
Subject: [InteropProject] InterOp Project - Status & next steps

 

This email originates from an external source. Stop and think before you click!


Dear all,

 

I would like to follow up around status & next steps around the InterOp work.

 

Next week is RWoT and in a month from now many of us will meet at IIW. It would be great if we could make a push towards a simple 'InterOp MVP'.

 

Orie already suggested a simple CLI based implementation (as MVP before using mobile wallets) which makes a lot of sense. There have been already some discussions last week in Slack, but I would like to make sure the broader community is included here hence the email follow up.

 

A few questions to kick off the discussion here:

 

1) Could we build a InterOp MVP based on the similar flow and actors like in our educational credential use-case? E.g. with the following setup:

    • one ISSUER to issue a credential (via command line rather than an educational website)
    • ideally, 2 different 'CLI Wallets' to receive, store and share the credential (based on different DID methods)
    • one VERIFIER to receive and validate the credential

If we do it all command-line based using existing libraries (?!) and split the work between at least 3-4 people/teams; we might be able to hack something together before IIW...  (maybe a little hackathon at RWoT, or the DIF F2F event before IIW)? 

 

I would expect that it would bring up some good questions which we could discuss at IIW (as well as start discussion the next phase with mobile wallets).

 

2) Any thoughts who could be the best candidates (teams) for the different parts given existing tools, demos or libraries? 

 

3) We currentky gave 7 open issues (https://github.com/decentralized-identity/interop-project/issues). Which ones are required to address for the simple 'InterOp MVP' demo?  Are we able to address these over the next week (given we have a few people at RWoT to discuss in person)?

 

Hope this makes sense? 

Looking forward to a good discussion here and some progress over the next 4 weeks!

 

Best,

Rouven

 


Old Mutual is a proudly Level 2 empowerment contributor company in terms of the Amended Financial Sector Generic Scorecard: Long-Term Assurers. .

Please access the link below to view our current BBBEE rating certificate. http://www.oldmutual.co.za/about-us/transformation/black-empowerment/bee-certificates.aspx

Please click on the following link to read the Old Mutual legal notice: http://www.oldmutual.co.za/about-us/governance/email-policy.aspx



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




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




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




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



Re: InterOp Project - Status & next steps

Dominic Wörner
 

Hi Orie,


AFAICT https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.md does regard a credential request as a DID Auth challenge. However, the credential request should have some unique information like a nonce that gets included in the verifiable presentation. Otherwise a man in the middle could re-use the signed presentation.

Best,
Dominic

Am Fr., 13. Sept. 2019 um 00:51 Uhr schrieb orie <orie@...>:

Awesome work!

One thing that occurred to me while updating the docs a while ago is this:

I still think we really need to demonstrate DID Auth, but do we really need DID Auth if we are using verifiable presentations?

Sure I can get a verifiable credential for a given did, but won't the presentation be impossible to create unless I control signing keys linked to the verifiable credential subject/holder?

I think the crux of this issue is that while verifying a JWS or JSON-LD Signature is a clearly defined process. Verifying a VC or VP is defined by:

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

What does it mean for me to present a membership credential issued to @Christian Lundkvist to the DIF verification service? Should that service only accept VPs that are signed by the subject of the VC the wrap?

Here the issue to track this: https://github.com/decentralized-identity/interop-project/issues/22

Please add your response to the github issue as well, for non mailing list members. 

OS



On Thu, Sep 12, 2019 at 3:58 PM Christian Lundkvist <christian.lundkvist@...> wrote:
Hi all, I created a PR which adds a server based interop demo. The web service can issue a credential, verify a credential and verify a presentation. It uses btcr for the Issuer and either btcr or elements for the holder.


Best,
Christian
On Sep 6, 2019, 11:31 -0400, orie <orie@...>, wrote:
This is probably more a topic for the VC working group, but I've been frustrated by this issue, IMO if an ethereum address is used to verify a signature, the JWS alg name should have ETH in it. Can you add some detail here?: https://github.com/w3c-dvcg/lds-ecdsa-secp256k1-2019/issues/1

I'm pretty sure that the uport did-jwt library supports both, ES256k and ES256K-R. From an interop perspective it seems a bit weird to be converting your public key to an ethereum address before trying to verify with a signature, but not if the signature alg makes it clear that you need to do that.

On Fri, Sep 6, 2019 at 11:08 AM Christian Lundkvist <christian.lundkvist@...> wrote:
> ES256K-R is not a requirement for using ETHR, however the default ETHR DIDs do not contain public keys, maybe thats what you mean?

Yep, that's what I meant! It's nice to be able to use the default ones.

Cheers,
Christian
On Sep 5, 2019, 18:29 -0400, Rouven Heck <rouven.heck@...>, wrote:
It would be great if we could find different teams/people to build the various 'entities' (obviously based on existing libraries/tools):

Is anyone interested to build:

A) the simple Issuer service (based on BTC-R?!)

B1 ) a CLI based holder 'wallet' based on DID method 2 
B2 ) a CLI based holder 'wallet' based on DID method 3 

C) a Verification service (checking the VCs from the issuer + the holder) - as per Christians flow)

If we could assign people/teams now to each of the entities we could coordinate more concretely on what needs to be spec'd and build before IIW. 

Cheers,
r


On Thu, Sep 5, 2019 at 5:48 PM orie <orie@...> wrote:
ES256K-R is not a requirement for using ETHR, however the default ETHR DIDs do not contain public keys, maybe thats what you mean?

We have adopted ES256K as the first JWS format for credentials, it requires a public key to verify.

As long as all DID Documents support publicKeyHex encoded secp256k1 keys, ES256K will work.

Feel free to add code / examples for ES256K-R, if you think its easier to show ETHR integration.

On Thu, Sep 5, 2019 at 4:22 PM Christian Lundkvist <christian.lundkvist@...> wrote:
Hi all, this is a sequence diagram for a very simple flow. The Issuer and Verifier would be automated services with an API, and the Holder would use a command line tool to call these services.

Ideally the Issuer would be a BTCR DID and the Holder would use a different DID method. If we choose say ethr here we would also need to support the ES256K-R algorithm (recoverable signatures) which would mean some more work.

Let me know what you think.




Cheers,
Christian
On Aug 30, 2019, 18:22 -0400, orie <orie@...>, wrote:
I added some sample code for a CLI demo: https://github.com/decentralized-identity/interop-project/issues/18

It lacks the DID Setup or Correct Credential Format, but has  working CLI demo using BTCR and JWS/JWT.

On Fri, Aug 30, 2019 at 4:54 PM Soma-Patel Anushka <asoma-patel@...> wrote:

Hi Rouven,

 

Thanks for including me in this.

 

I have shared this info with some members of the south African financial blockchain consortium to see if they are keen to participate.

 

I will let you know if there is any interest.

 

Regards,

Anushka

+27847547943

 

From: InteropProject@DIF.groups.io <InteropProject@DIF.groups.io> On Behalf Of Rouven Heck
Sent: 30 August 2019 03:25 PM
To: interopproject@dif.groups.io; Daniel Buchner <daniel.buchner@...>; Kyle Den Hartog <kyle.denhartog@...>; Joachim Lohkamp | Jolocom <joachim@...>; Kim Hamilton <kimdhamilton@...>; Carsten Stöcker <carsten.stoecker@...>
Subject: [InteropProject] InterOp Project - Status & next steps

 

This email originates from an external source. Stop and think before you click!


Dear all,

 

I would like to follow up around status & next steps around the InterOp work.

 

Next week is RWoT and in a month from now many of us will meet at IIW. It would be great if we could make a push towards a simple 'InterOp MVP'.

 

Orie already suggested a simple CLI based implementation (as MVP before using mobile wallets) which makes a lot of sense. There have been already some discussions last week in Slack, but I would like to make sure the broader community is included here hence the email follow up.

 

A few questions to kick off the discussion here:

 

1) Could we build a InterOp MVP based on the similar flow and actors like in our educational credential use-case? E.g. with the following setup:

    • one ISSUER to issue a credential (via command line rather than an educational website)
    • ideally, 2 different 'CLI Wallets' to receive, store and share the credential (based on different DID methods)
    • one VERIFIER to receive and validate the credential

If we do it all command-line based using existing libraries (?!) and split the work between at least 3-4 people/teams; we might be able to hack something together before IIW...  (maybe a little hackathon at RWoT, or the DIF F2F event before IIW)? 

 

I would expect that it would bring up some good questions which we could discuss at IIW (as well as start discussion the next phase with mobile wallets).

 

2) Any thoughts who could be the best candidates (teams) for the different parts given existing tools, demos or libraries? 

 

3) We currentky gave 7 open issues (https://github.com/decentralized-identity/interop-project/issues). Which ones are required to address for the simple 'InterOp MVP' demo?  Are we able to address these over the next week (given we have a few people at RWoT to discuss in person)?

 

Hope this makes sense? 

Looking forward to a good discussion here and some progress over the next 4 weeks!

 

Best,

Rouven

 


Old Mutual is a proudly Level 2 empowerment contributor company in terms of the Amended Financial Sector Generic Scorecard: Long-Term Assurers. .

Please access the link below to view our current BBBEE rating certificate. http://www.oldmutual.co.za/about-us/transformation/black-empowerment/bee-certificates.aspx

Please click on the following link to read the Old Mutual legal notice: http://www.oldmutual.co.za/about-us/governance/email-policy.aspx



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




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




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




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



Re: InterOp Project - Status & next steps

Dominic Wörner
 

Good morning,

Christian, is this interop work only concerned with having common VC representations and interoperability between the DID methods?
I'm more concerned with the credential negotiation/communication protocols. Is the DIDcomm work from the Aries community the way to go?

Best, 
Dominic

Am Fr., 13. Sept. 2019 um 00:51 Uhr schrieb orie <orie@...>:

Awesome work!

One thing that occurred to me while updating the docs a while ago is this:

I still think we really need to demonstrate DID Auth, but do we really need DID Auth if we are using verifiable presentations?

Sure I can get a verifiable credential for a given did, but won't the presentation be impossible to create unless I control signing keys linked to the verifiable credential subject/holder?

I think the crux of this issue is that while verifying a JWS or JSON-LD Signature is a clearly defined process. Verifying a VC or VP is defined by:

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

What does it mean for me to present a membership credential issued to @Christian Lundkvist to the DIF verification service? Should that service only accept VPs that are signed by the subject of the VC the wrap?

Here the issue to track this: https://github.com/decentralized-identity/interop-project/issues/22

Please add your response to the github issue as well, for non mailing list members. 

OS



On Thu, Sep 12, 2019 at 3:58 PM Christian Lundkvist <christian.lundkvist@...> wrote:
Hi all, I created a PR which adds a server based interop demo. The web service can issue a credential, verify a credential and verify a presentation. It uses btcr for the Issuer and either btcr or elements for the holder.


Best,
Christian
On Sep 6, 2019, 11:31 -0400, orie <orie@...>, wrote:
This is probably more a topic for the VC working group, but I've been frustrated by this issue, IMO if an ethereum address is used to verify a signature, the JWS alg name should have ETH in it. Can you add some detail here?: https://github.com/w3c-dvcg/lds-ecdsa-secp256k1-2019/issues/1

I'm pretty sure that the uport did-jwt library supports both, ES256k and ES256K-R. From an interop perspective it seems a bit weird to be converting your public key to an ethereum address before trying to verify with a signature, but not if the signature alg makes it clear that you need to do that.

On Fri, Sep 6, 2019 at 11:08 AM Christian Lundkvist <christian.lundkvist@...> wrote:
> ES256K-R is not a requirement for using ETHR, however the default ETHR DIDs do not contain public keys, maybe thats what you mean?

Yep, that's what I meant! It's nice to be able to use the default ones.

Cheers,
Christian
On Sep 5, 2019, 18:29 -0400, Rouven Heck <rouven.heck@...>, wrote:
It would be great if we could find different teams/people to build the various 'entities' (obviously based on existing libraries/tools):

Is anyone interested to build:

A) the simple Issuer service (based on BTC-R?!)

B1 ) a CLI based holder 'wallet' based on DID method 2 
B2 ) a CLI based holder 'wallet' based on DID method 3 

C) a Verification service (checking the VCs from the issuer + the holder) - as per Christians flow)

If we could assign people/teams now to each of the entities we could coordinate more concretely on what needs to be spec'd and build before IIW. 

Cheers,
r


On Thu, Sep 5, 2019 at 5:48 PM orie <orie@...> wrote:
ES256K-R is not a requirement for using ETHR, however the default ETHR DIDs do not contain public keys, maybe thats what you mean?

We have adopted ES256K as the first JWS format for credentials, it requires a public key to verify.

As long as all DID Documents support publicKeyHex encoded secp256k1 keys, ES256K will work.

Feel free to add code / examples for ES256K-R, if you think its easier to show ETHR integration.

On Thu, Sep 5, 2019 at 4:22 PM Christian Lundkvist <christian.lundkvist@...> wrote:
Hi all, this is a sequence diagram for a very simple flow. The Issuer and Verifier would be automated services with an API, and the Holder would use a command line tool to call these services.

Ideally the Issuer would be a BTCR DID and the Holder would use a different DID method. If we choose say ethr here we would also need to support the ES256K-R algorithm (recoverable signatures) which would mean some more work.

Let me know what you think.




Cheers,
Christian
On Aug 30, 2019, 18:22 -0400, orie <orie@...>, wrote:
I added some sample code for a CLI demo: https://github.com/decentralized-identity/interop-project/issues/18

It lacks the DID Setup or Correct Credential Format, but has  working CLI demo using BTCR and JWS/JWT.

On Fri, Aug 30, 2019 at 4:54 PM Soma-Patel Anushka <asoma-patel@...> wrote:

Hi Rouven,

 

Thanks for including me in this.

 

I have shared this info with some members of the south African financial blockchain consortium to see if they are keen to participate.

 

I will let you know if there is any interest.

 

Regards,

Anushka

+27847547943

 

From: InteropProject@DIF.groups.io <InteropProject@DIF.groups.io> On Behalf Of Rouven Heck
Sent: 30 August 2019 03:25 PM
To: interopproject@dif.groups.io; Daniel Buchner <daniel.buchner@...>; Kyle Den Hartog <kyle.denhartog@...>; Joachim Lohkamp | Jolocom <joachim@...>; Kim Hamilton <kimdhamilton@...>; Carsten Stöcker <carsten.stoecker@...>
Subject: [InteropProject] InterOp Project - Status & next steps

 

This email originates from an external source. Stop and think before you click!


Dear all,

 

I would like to follow up around status & next steps around the InterOp work.

 

Next week is RWoT and in a month from now many of us will meet at IIW. It would be great if we could make a push towards a simple 'InterOp MVP'.

 

Orie already suggested a simple CLI based implementation (as MVP before using mobile wallets) which makes a lot of sense. There have been already some discussions last week in Slack, but I would like to make sure the broader community is included here hence the email follow up.

 

A few questions to kick off the discussion here:

 

1) Could we build a InterOp MVP based on the similar flow and actors like in our educational credential use-case? E.g. with the following setup:

    • one ISSUER to issue a credential (via command line rather than an educational website)
    • ideally, 2 different 'CLI Wallets' to receive, store and share the credential (based on different DID methods)
    • one VERIFIER to receive and validate the credential

If we do it all command-line based using existing libraries (?!) and split the work between at least 3-4 people/teams; we might be able to hack something together before IIW...  (maybe a little hackathon at RWoT, or the DIF F2F event before IIW)? 

 

I would expect that it would bring up some good questions which we could discuss at IIW (as well as start discussion the next phase with mobile wallets).

 

2) Any thoughts who could be the best candidates (teams) for the different parts given existing tools, demos or libraries? 

 

3) We currentky gave 7 open issues (https://github.com/decentralized-identity/interop-project/issues). Which ones are required to address for the simple 'InterOp MVP' demo?  Are we able to address these over the next week (given we have a few people at RWoT to discuss in person)?

 

Hope this makes sense? 

Looking forward to a good discussion here and some progress over the next 4 weeks!

 

Best,

Rouven

 


Old Mutual is a proudly Level 2 empowerment contributor company in terms of the Amended Financial Sector Generic Scorecard: Long-Term Assurers. .

Please access the link below to view our current BBBEE rating certificate. http://www.oldmutual.co.za/about-us/transformation/black-empowerment/bee-certificates.aspx

Please click on the following link to read the Old Mutual legal notice: http://www.oldmutual.co.za/about-us/governance/email-policy.aspx



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




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




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




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



Re: InterOp Project - Status & next steps

orie
 

Awesome work!

One thing that occurred to me while updating the docs a while ago is this:

I still think we really need to demonstrate DID Auth, but do we really need DID Auth if we are using verifiable presentations?

Sure I can get a verifiable credential for a given did, but won't the presentation be impossible to create unless I control signing keys linked to the verifiable credential subject/holder?

I think the crux of this issue is that while verifying a JWS or JSON-LD Signature is a clearly defined process. Verifying a VC or VP is defined by:

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

What does it mean for me to present a membership credential issued to @Christian Lundkvist to the DIF verification service? Should that service only accept VPs that are signed by the subject of the VC the wrap?

Here the issue to track this: https://github.com/decentralized-identity/interop-project/issues/22

Please add your response to the github issue as well, for non mailing list members. 

OS



On Thu, Sep 12, 2019 at 3:58 PM Christian Lundkvist <christian.lundkvist@...> wrote:
Hi all, I created a PR which adds a server based interop demo. The web service can issue a credential, verify a credential and verify a presentation. It uses btcr for the Issuer and either btcr or elements for the holder.


Best,
Christian
On Sep 6, 2019, 11:31 -0400, orie <orie@...>, wrote:
This is probably more a topic for the VC working group, but I've been frustrated by this issue, IMO if an ethereum address is used to verify a signature, the JWS alg name should have ETH in it. Can you add some detail here?: https://github.com/w3c-dvcg/lds-ecdsa-secp256k1-2019/issues/1

I'm pretty sure that the uport did-jwt library supports both, ES256k and ES256K-R. From an interop perspective it seems a bit weird to be converting your public key to an ethereum address before trying to verify with a signature, but not if the signature alg makes it clear that you need to do that.

On Fri, Sep 6, 2019 at 11:08 AM Christian Lundkvist <christian.lundkvist@...> wrote:
> ES256K-R is not a requirement for using ETHR, however the default ETHR DIDs do not contain public keys, maybe thats what you mean?

Yep, that's what I meant! It's nice to be able to use the default ones.

Cheers,
Christian
On Sep 5, 2019, 18:29 -0400, Rouven Heck <rouven.heck@...>, wrote:
It would be great if we could find different teams/people to build the various 'entities' (obviously based on existing libraries/tools):

Is anyone interested to build:

A) the simple Issuer service (based on BTC-R?!)

B1 ) a CLI based holder 'wallet' based on DID method 2 
B2 ) a CLI based holder 'wallet' based on DID method 3 

C) a Verification service (checking the VCs from the issuer + the holder) - as per Christians flow)

If we could assign people/teams now to each of the entities we could coordinate more concretely on what needs to be spec'd and build before IIW. 

Cheers,
r


On Thu, Sep 5, 2019 at 5:48 PM orie <orie@...> wrote:
ES256K-R is not a requirement for using ETHR, however the default ETHR DIDs do not contain public keys, maybe thats what you mean?

We have adopted ES256K as the first JWS format for credentials, it requires a public key to verify.

As long as all DID Documents support publicKeyHex encoded secp256k1 keys, ES256K will work.

Feel free to add code / examples for ES256K-R, if you think its easier to show ETHR integration.

On Thu, Sep 5, 2019 at 4:22 PM Christian Lundkvist <christian.lundkvist@...> wrote:
Hi all, this is a sequence diagram for a very simple flow. The Issuer and Verifier would be automated services with an API, and the Holder would use a command line tool to call these services.

Ideally the Issuer would be a BTCR DID and the Holder would use a different DID method. If we choose say ethr here we would also need to support the ES256K-R algorithm (recoverable signatures) which would mean some more work.

Let me know what you think.




Cheers,
Christian
On Aug 30, 2019, 18:22 -0400, orie <orie@...>, wrote:
I added some sample code for a CLI demo: https://github.com/decentralized-identity/interop-project/issues/18

It lacks the DID Setup or Correct Credential Format, but has  working CLI demo using BTCR and JWS/JWT.

On Fri, Aug 30, 2019 at 4:54 PM Soma-Patel Anushka <asoma-patel@...> wrote:

Hi Rouven,

 

Thanks for including me in this.

 

I have shared this info with some members of the south African financial blockchain consortium to see if they are keen to participate.

 

I will let you know if there is any interest.

 

Regards,

Anushka

+27847547943

 

From: InteropProject@DIF.groups.io <InteropProject@DIF.groups.io> On Behalf Of Rouven Heck
Sent: 30 August 2019 03:25 PM
To: interopproject@dif.groups.io; Daniel Buchner <daniel.buchner@...>; Kyle Den Hartog <kyle.denhartog@...>; Joachim Lohkamp | Jolocom <joachim@...>; Kim Hamilton <kimdhamilton@...>; Carsten Stöcker <carsten.stoecker@...>
Subject: [InteropProject] InterOp Project - Status & next steps

 

This email originates from an external source. Stop and think before you click!


Dear all,

 

I would like to follow up around status & next steps around the InterOp work.

 

Next week is RWoT and in a month from now many of us will meet at IIW. It would be great if we could make a push towards a simple 'InterOp MVP'.

 

Orie already suggested a simple CLI based implementation (as MVP before using mobile wallets) which makes a lot of sense. There have been already some discussions last week in Slack, but I would like to make sure the broader community is included here hence the email follow up.

 

A few questions to kick off the discussion here:

 

1) Could we build a InterOp MVP based on the similar flow and actors like in our educational credential use-case? E.g. with the following setup:

    • one ISSUER to issue a credential (via command line rather than an educational website)
    • ideally, 2 different 'CLI Wallets' to receive, store and share the credential (based on different DID methods)
    • one VERIFIER to receive and validate the credential

If we do it all command-line based using existing libraries (?!) and split the work between at least 3-4 people/teams; we might be able to hack something together before IIW...  (maybe a little hackathon at RWoT, or the DIF F2F event before IIW)? 

 

I would expect that it would bring up some good questions which we could discuss at IIW (as well as start discussion the next phase with mobile wallets).

 

2) Any thoughts who could be the best candidates (teams) for the different parts given existing tools, demos or libraries? 

 

3) We currentky gave 7 open issues (https://github.com/decentralized-identity/interop-project/issues). Which ones are required to address for the simple 'InterOp MVP' demo?  Are we able to address these over the next week (given we have a few people at RWoT to discuss in person)?

 

Hope this makes sense? 

Looking forward to a good discussion here and some progress over the next 4 weeks!

 

Best,

Rouven

 


Old Mutual is a proudly Level 2 empowerment contributor company in terms of the Amended Financial Sector Generic Scorecard: Long-Term Assurers. .

Please access the link below to view our current BBBEE rating certificate. http://www.oldmutual.co.za/about-us/transformation/black-empowerment/bee-certificates.aspx

Please click on the following link to read the Old Mutual legal notice: http://www.oldmutual.co.za/about-us/governance/email-policy.aspx



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




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




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




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



Re: InterOp Project - Status & next steps

Christian Lundkvist
 

Hi all, I created a PR which adds a server based interop demo. The web service can issue a credential, verify a credential and verify a presentation. It uses btcr for the Issuer and either btcr or elements for the holder.


Best,
Christian

On Sep 6, 2019, 11:31 -0400, orie <orie@...>, wrote:
This is probably more a topic for the VC working group, but I've been frustrated by this issue, IMO if an ethereum address is used to verify a signature, the JWS alg name should have ETH in it. Can you add some detail here?: https://github.com/w3c-dvcg/lds-ecdsa-secp256k1-2019/issues/1

I'm pretty sure that the uport did-jwt library supports both, ES256k and ES256K-R. From an interop perspective it seems a bit weird to be converting your public key to an ethereum address before trying to verify with a signature, but not if the signature alg makes it clear that you need to do that.

On Fri, Sep 6, 2019 at 11:08 AM Christian Lundkvist <christian.lundkvist@...> wrote:
> ES256K-R is not a requirement for using ETHR, however the default ETHR DIDs do not contain public keys, maybe thats what you mean?

Yep, that's what I meant! It's nice to be able to use the default ones.

Cheers,
Christian
On Sep 5, 2019, 18:29 -0400, Rouven Heck <rouven.heck@...>, wrote:
It would be great if we could find different teams/people to build the various 'entities' (obviously based on existing libraries/tools):

Is anyone interested to build:

A) the simple Issuer service (based on BTC-R?!)

B1 ) a CLI based holder 'wallet' based on DID method 2 
B2 ) a CLI based holder 'wallet' based on DID method 3 

C) a Verification service (checking the VCs from the issuer + the holder) - as per Christians flow)

If we could assign people/teams now to each of the entities we could coordinate more concretely on what needs to be spec'd and build before IIW. 

Cheers,
r


On Thu, Sep 5, 2019 at 5:48 PM orie <orie@...> wrote:
ES256K-R is not a requirement for using ETHR, however the default ETHR DIDs do not contain public keys, maybe thats what you mean?

We have adopted ES256K as the first JWS format for credentials, it requires a public key to verify.

As long as all DID Documents support publicKeyHex encoded secp256k1 keys, ES256K will work.

Feel free to add code / examples for ES256K-R, if you think its easier to show ETHR integration.

On Thu, Sep 5, 2019 at 4:22 PM Christian Lundkvist <christian.lundkvist@...> wrote:
Hi all, this is a sequence diagram for a very simple flow. The Issuer and Verifier would be automated services with an API, and the Holder would use a command line tool to call these services.

Ideally the Issuer would be a BTCR DID and the Holder would use a different DID method. If we choose say ethr here we would also need to support the ES256K-R algorithm (recoverable signatures) which would mean some more work.

Let me know what you think.




Cheers,
Christian
On Aug 30, 2019, 18:22 -0400, orie <orie@...>, wrote:
I added some sample code for a CLI demo: https://github.com/decentralized-identity/interop-project/issues/18

It lacks the DID Setup or Correct Credential Format, but has  working CLI demo using BTCR and JWS/JWT.

On Fri, Aug 30, 2019 at 4:54 PM Soma-Patel Anushka <asoma-patel@...> wrote:

Hi Rouven,

 

Thanks for including me in this.

 

I have shared this info with some members of the south African financial blockchain consortium to see if they are keen to participate.

 

I will let you know if there is any interest.

 

Regards,

Anushka

+27847547943

 

From: InteropProject@DIF.groups.io <InteropProject@DIF.groups.io> On Behalf Of Rouven Heck
Sent: 30 August 2019 03:25 PM
To: interopproject@dif.groups.io; Daniel Buchner <daniel.buchner@...>; Kyle Den Hartog <kyle.denhartog@...>; Joachim Lohkamp | Jolocom <joachim@...>; Kim Hamilton <kimdhamilton@...>; Carsten Stöcker <carsten.stoecker@...>
Subject: [InteropProject] InterOp Project - Status & next steps

 

This email originates from an external source. Stop and think before you click!


Dear all,

 

I would like to follow up around status & next steps around the InterOp work.

 

Next week is RWoT and in a month from now many of us will meet at IIW. It would be great if we could make a push towards a simple 'InterOp MVP'.

 

Orie already suggested a simple CLI based implementation (as MVP before using mobile wallets) which makes a lot of sense. There have been already some discussions last week in Slack, but I would like to make sure the broader community is included here hence the email follow up.

 

A few questions to kick off the discussion here:

 

1) Could we build a InterOp MVP based on the similar flow and actors like in our educational credential use-case? E.g. with the following setup:

    • one ISSUER to issue a credential (via command line rather than an educational website)
    • ideally, 2 different 'CLI Wallets' to receive, store and share the credential (based on different DID methods)
    • one VERIFIER to receive and validate the credential

If we do it all command-line based using existing libraries (?!) and split the work between at least 3-4 people/teams; we might be able to hack something together before IIW...  (maybe a little hackathon at RWoT, or the DIF F2F event before IIW)? 

 

I would expect that it would bring up some good questions which we could discuss at IIW (as well as start discussion the next phase with mobile wallets).

 

2) Any thoughts who could be the best candidates (teams) for the different parts given existing tools, demos or libraries? 

 

3) We currentky gave 7 open issues (https://github.com/decentralized-identity/interop-project/issues). Which ones are required to address for the simple 'InterOp MVP' demo?  Are we able to address these over the next week (given we have a few people at RWoT to discuss in person)?

 

Hope this makes sense? 

Looking forward to a good discussion here and some progress over the next 4 weeks!

 

Best,

Rouven

 


Old Mutual is a proudly Level 2 empowerment contributor company in terms of the Amended Financial Sector Generic Scorecard: Long-Term Assurers. .

Please access the link below to view our current BBBEE rating certificate. http://www.oldmutual.co.za/about-us/transformation/black-empowerment/bee-certificates.aspx

Please click on the following link to read the Old Mutual legal notice: http://www.oldmutual.co.za/about-us/governance/email-policy.aspx



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




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




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