Add support for displaying who issued a credential about aries-mobile-agent-react-native HOT 18 CLOSED

You can already know who issued the credential based on the label from the connection associated with it. Isn't that enough?

from aries-mobile-agent-react-native.

@TimoGlastra Maybe. What's the workflow to get it? Use useConnectionById with the ID from the credential and then the object returned should have that label?

EDIT: I think the challenge is the label is self-attested: It can be added by the inviter (when sent) or invitee. So not overly secure - no?

from aries-mobile-agent-react-native.

Yes but I also wouldn't account on the alias on the ledger being secure. I think that is a free form field. Any endorser can write to the ledger

Sam did a presentation on this a while ago: https://hackmd.io/@TelegramSam/Hy32toMkD#/ we should find other ways to establish trust after creating a connection. E.g in the case of BCGov a proof that you are a registered business.

from aries-mobile-agent-react-native.

@TimoGlastra the question is about what to display for the issuer of the credential. The alias on the connection is self-attested, so I don't think that makes sense (in that the inviter/invitee can use whatever they want in the label). Also if the holder deletes the connection, but still holds the credential, then they no longer have the connection alias to display.

The hackmd doc you link ^^^ is related to what to display for connections, not credentials (?)

I thought that for credentials, you could extract the issuer DID from the cred def ID, and then lookup the alias for this DID on the ledger, are you saying that isn't secure? Who is allowed to update someone else's DID attributes on the leger?

from aries-mobile-agent-react-native.

When credentials don't contain any information on who issued a credential the Alias can be used as a convention.

@jleach a credential will always contain a credential definition id, which contains the public DID of the issuer

from aries-mobile-agent-react-native.

When credentials don't contain any information on who issued a credential the Alias can be used as a convention.

@jleach a credential will always contain a credential definition id, which contains the public DID of the issuer

Noted. @ianco I was thinking something human readable (context of displaying something for a person to see).

from aries-mobile-agent-react-native.

When credentials don't contain any information on who issued a credential the Alias can be used as a convention.

@jleach a credential will always contain a credential definition id, which contains the public DID of the issuer

Noted. @ianco I was thinking something human readable (context of displaying something for a person to see).

Ah ok got it. I don't think credentials will ever contain human-readable context of the issuer (at least in the current form), hence the current approaches to use the schema name, cred def tag, etc

from aries-mobile-agent-react-native.

Maybe I'm misunderstanding the question here, but what I'm trying to say that both are just as insecure.

E.g we as Animo have a DID on the ledger with an alias: https://indyscan.io/tx/SOVRIN_MAINNET/domain/75419 We didn't write this DID to the ledger ourselves and the Alias was set by the entity submitting the DID.

So as I understand it, both labels are self attested. There is indeed the case of a connection being removed.

Not saying we shouldn't use the ledger Alias. Just that I think we shouldn't use it for trustworthiness. But maybe I'm missing some important things here

from aries-mobile-agent-react-native.

Agree with everything you just said.

However I think the trustworthiness of the DID info on the ledger will be based on the process around how the DID (and related info) is written. It has to go through one of the trustees (I think is the correct role) and as part of their process they should confirm who you are. For example if I send an email to one of the nodes on the production SOVRIN network and claim that I'm Animo, that node should verify that before they write my DID. That should be defined in the governance structure of the network, i.e. SOVRIN production network shouldn't allow nodes unless they agree to verify the identity of public DID's that they are writing to the ledger.

from aries-mobile-agent-react-native.

The process that @jleach and I just discussed is - when a holder receives a credential, then the wallet will display the issuer as follows:

• extract the issuer DID from the cred def id, and then lookup the alias on the ledger
• if there is no alias, then display the label from the connection

Ideally the holder should be able to request a proof from the issuer that (a) they are who they claim, and (b) they have some sort of authority to issue credentials, but AFAIK there are no standards around this right now (and the current set of wallets don't have the capability to ask for proofs)

from aries-mobile-agent-react-native.

This makes sense. Thanks for taking the time to explain it to me @ianco! :)

from aries-mobile-agent-react-native.

@TimoGlastra Created this issue in the AFJ repo to track the lower level work for this change. Feedback as to where to start welcome.

from aries-mobile-agent-react-native.

I did a quick scan through the SOVRIN docs and couldn't find anything specific around how to confirm identity when writing a DID to the ledger: https://sovrin.org/library/sovrin-governance-framework/

... however there is some general language around methods of trust, including contracts, which I expect would apply ... @swcurran ?

from aries-mobile-agent-react-native.

@ianco -- there is nothing in cryptographic in the ledger to specify what gets written to the ledger. To be able to write to a Sovrin ledger, you have to have permission (Endorser) or get your transaction signed by an Endorser. To be an Endorser you have to sign a legal agreement and demonstrate to the Sovrin Foundation that your organization is a registered entity. However, there is no tie between what the Endorser writes to the ledger and the name they put into the "Alias" field of an ATTRIB Transaction.

For the "Issuer", I would start with what is done in the ACA-Py and .NET frameworks to see where they are getting that value. Is it coming from an NYM (corrected based on @ianco 's comment below vvvv) transaction on the ledger, and if so, what are they doing if there is no alias in the NYM. Or are they using the "Alias" from the connection the holder has with the issuer?

from aries-mobile-agent-react-native.

Hmmmm doing a quick scan of the SOVRIN mainnet (using the famous VON ledger browser https://sovrin-mainnet-browser.vonx.io/):

• Most NYM transactions do not have an alias (Animo is one of the few that do)
• Most ATTRIB transactions contain only the endpoint (no other metadata)
• Most endpoints are 127.0.0.1, localhost or some variation of *.ngrok.io, which implies that almost all data on SOVRIN mainnet is non-production

from aries-mobile-agent-react-native.

@jleach asked in chat about how the alias appears on the ledger. Figured it was better to discuss this here.

Some agents will publish their URL for a direct connection to the ledger (in the DIDdoc I presume). What’s the process for editing that if ones IP changes or, how about adding additional information to the DIDdoc and later editing it? Also, can the “Alias” be edited on the ledger or is it imutable?

The URL (endpoint) an Indy issuer are by convention are published in an "ATTRIB" transaction of type (raw value) "endpoint". The alias can be set on the NYM transaction (this is corrected per Ian's note above ^^^) This can be retrieved in two ways:

• If you are using a library that is a DID Resolver for "did:sov", you should be able to pass in a DID (did:sov:1234), and get back a proper DIDDoc that has data from the most recent versions of the DID (aka "NYM") and ATTRIB on the ledger.
• If you are querying the Indy ledger directly, you would make two calls to the ledger to read the DID (GET_NYM Request) and it's related ATTRIB "endpoint" (GET_ATTRIB request), and process the responses as needed. This is the same thing a DID Resolver Library does above.

As far as the issuer updating the data -- they just write new "NYM" and "ATTRIB" transactions as needed. A new NYM must have the same identifier, but can have a new verkey, allowing the controller of the DID to rotate the key. If a new ATTRIB is written, the "GET_ATTRIB" call will return the most recent value. Note that there are ways to directly read the old values from the ledger via a "GET_TXN" call by ledger identifier.

from aries-mobile-agent-react-native.

Thanks Ian - you are right about the Alias -- it is on the NYM. And it is rarely used...

from aries-mobile-agent-react-native.

I think we are full circle now and using the alias does not seem like a good solution. Best we can hope for is to use the label in the connection and hope for the best. Will add this to the greater working group conversation on how to make VCs more human consumable.

from aries-mobile-agent-react-native.