toggle quoted messageShow quoted text
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.
On Fri, Sep 13, 2019 at 09:01 Dominic Wörner <dom.woe@...
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?
Am Fr., 13. Sept. 2019 um 00:51 Uhr schrieb orie <orie@...>:
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.
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.
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.
> 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.
On Sep 5, 2019, 18:29 -0400, Rouven Heck <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.
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.
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.
On Aug 30, 2019, 18:22 -0400, orie <orie@...>, wrote:
On Fri, Aug 30, 2019 at 4:54 PM Soma-Patel Anushka <asoma-patel@...
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.
From: InteropProject@DIF.groups.io <InteropProject@DIF.groups.io> On Behalf Of Rouven Heck
Sent: 30 August 2019 03:25 PM
To: firstname.lastname@example.org; 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!
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?
Looking forward to a good discussion here and some progress over the next 4 weeks!
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
Chief Technology Officer
Chief Technology Officer
Chief Technology Officer
Chief Technology Officer