Topics

InterOp Project - Status & next steps


Rouven Heck
 

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


orie
 

Sadly, I won't be at RWOT.

I've added a single ticket for the CLI demo: https://github.com/decentralized-identity/interop-project/issues/18

We have a lot of what is needed to solve this already.

If anyone is working on this at RWOT and wants assistance, please ping me by slack or email.

I will be traveling but should be able to respond.

OS


On Fri, Aug 30, 2019 at 8:25 AM Rouven Heck <rouven.heck@...> wrote:
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



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



orie
 

To answer the questions more directly:



On Fri, Aug 30, 2019 at 9:54 AM orie via Groups.Io <orie=transmute.industries@groups.io> wrote:
Sadly, I won't be at RWOT.

I've added a single ticket for the CLI demo: https://github.com/decentralized-identity/interop-project/issues/18

We have a lot of what is needed to solve this already.

If anyone is working on this at RWOT and wants assistance, please ping me by slack or email.

I will be traveling but should be able to respond.

OS

On Fri, Aug 30, 2019 at 8:25 AM Rouven Heck <rouven.heck@...> wrote:
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).

I think this is achievable, happy to lead some of this at IIW. 

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

I'm biased, and Transmute has a couple of other priorities, but I'm sure I can assist to some degree. I think we would be well positioned to create the credential issuance and verification library using the universal resolver. Christian Lundkvist mentioned some interest in this as well

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)?


Many of these issues are long running interop support discussions, and in some ways not directly relevant to an MVP Demo. Thats why I created this specific ticket to address the proposal from this email:

https://github.com/decentralized-identity/interop-project/issues/18


 
Hope this makes sense? 
Looking forward to a good discussion here and some progress over the next 4 weeks!

Best,
Rouven



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




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



Christian Lundkvist
 

Hi Orie,

I think creating a simple & focused CLI demo would be doable, as described in the PR you linked to. Basically start a CLI tool issuing a credential (perhaps start with a JSON file describing the credential data and spit out a signed credential). 

Then send the credential (could be just in an email) and finally show a CLI tool verifying the credential (ideally using the Universal Resolver).

Cheers,
Christian

On Aug 30, 2019, 11:43 -0400, orie <orie@...>, wrote:
To answer the questions more directly:



On Fri, Aug 30, 2019 at 9:54 AM orie via Groups.Io <orie=transmute.industries@groups.io> wrote:
Sadly, I won't be at RWOT.

I've added a single ticket for the CLI demo: https://github.com/decentralized-identity/interop-project/issues/18

We have a lot of what is needed to solve this already.

If anyone is working on this at RWOT and wants assistance, please ping me by slack or email.

I will be traveling but should be able to respond.

OS

On Fri, Aug 30, 2019 at 8:25 AM Rouven Heck <rouven.heck@...> wrote:
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).

I think this is achievable, happy to lead some of this at IIW. 

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

I'm biased, and Transmute has a couple of other priorities, but I'm sure I can assist to some degree. I think we would be well positioned to create the credential issuance and verification library using the universal resolver. Christian Lundkvist mentioned some interest in this as well

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)?


Many of these issues are long running interop support discussions, and in some ways not directly relevant to an MVP Demo. Thats why I created this specific ticket to address the proposal from this email:

https://github.com/decentralized-identity/interop-project/issues/18


 
Hope this makes sense? 
Looking forward to a good discussion here and some progress over the next 4 weeks!

Best,
Rouven



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




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



Soma-Patel Anushka
 

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
 

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



Christian Lundkvist
 

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



Christian Lundkvist
 

Note that the simple flow above does not protect against replay attacks, it’s designed primarily for simplicity in mind.

Cheers,
Christian

On Sep 5, 2019, 16:22 -0400, Christian Lundkvist via Groups.Io <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
 

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



Rouven Heck
 

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



Christian Lundkvist
 

> 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
 

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



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



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



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



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