Expanding use cases for Credentials

[nitinmish]

Context

Each provider may have possibly numerous credentials associated that may vary from being a Badge, Certificates, Licenses etc to enhance the trust factor associated. It is possible that a provider may have multiple credentials associated and may like to send them in an array for buyer Apps to render on their side. Credentials will vary basis the requirement of a transactions. For example, export norms and licenses vary from country to country and a provider may like to send such certificates pertaining to a context, which in turn can be processed by a consumer App and rendered for a consumer to take a decision.

Problem Statement

Currently, the Credentials reference in core protocol only captures three fields which in turn is referred as attribute creds against each provider. Licenses may have many facets and credentials section must capture additional attributes. Current structure of Credentials meta section is as follows:

description: Describes a credential of an entity - Person or Organization
type: object
properties:
id:
type: string
type:
type: string
default: "VerifiableCredential"
url:
description: URL of the credential
type: string
format: uri

Proposal

We propose the section to be changed to following in order to allow providers provide verifiable credentials to consumers:

description: Describes a credential of an entity - Person or Organization
type: object
properties:
id:
type: string
type:
type: string
default: "VerifiableCredential"
url:
description: URL of the credential
type: string
format: uri
desc:
description: Short Description of Credential being shared
type: string
verifyUrl:
description: Verification URL for verifying user credentials
type: string
format: uri
valid_from:
type:string
format: date-time
expires_on: string
format: date-time

[nitinmish]

@ravi-prakash-v @BLR-0118 @venkatramanm

[nitinmish]

A sample JSON is also pasted below for reference.

{
"creds": [{
"id": "ESG-12345678",
"desc": "Dun&Bradstreet ESG Badge No. ESG-12345678",
"url": "https://abcd.cdn.com/images/badge-img",
"Verify_url": "https://abcd.dnb.com/verify?id=’ESG-12345678'",
"valid_from": "2023-02-03T00:00:00:000Z",
"expires_on": "2024-02-03T23:59:59:999Z"
}, {
"id": "Auth33567",
"desc": "Authorised Samsung Dealers",
"link": "https://abcd.cdn.com/images/badge-img",
"Verify_url": "https://abcd.samsung.com/verify?id='Auth33567'",
"valid_from": "2023-02-03T00:00:00:000Z",
"expires_on": "2024-02-03T23:59:59:999Z"
}]
}

[venkatramanm]

The need for 2 URLs is not clear. A credential provider-hosted (badge or verify) URL may be enough. right?

From and To date is a good suggestion. What about a status field? It could say VALID, EXPIRED, REVOKED...
-- These fields may also be shown in the badge or verification URL.

Is there any logic that someone is building around these additional fields?

There are 2 schema objects possibly relevant here. Descriptor and Authorization. (Authorization is a type of credential) , We can possibly derive authorization from Credential moving some of the attributes from Authorization to Credential. Additionally, if we have a descriptor inside to hold descriptions, it may suffice.

@ravi-prakash-v your thoughts?

[nitinmish]

We are working on exports and few other use cases. In case of exports, the licenses could be proof of documents that can be uploaded through a URL and there are APIs available that can verify the credential. Similarly, badges could be a simple thumbnail of a badge, such as Platinum rating of a seller by D&B which can be displayed along with store page on consumer app, while the URL could be verifiable link that may return additional values. For exports this will be critical as consumer side needs to verify documents and get a verifiable link to authenticate the license as provided. All attributes can be either / or.

@ravi-prakash-v @pramodkvarma @BLR-0118 @venkatramanm

[venkatramanm]

My opinion:
The verification url should ideally not be sent by the one who is claiming to have a certain credential. For e.g if I send a fake aadhar number and a fake url that claims the aadhar to be genuine.
The whole claim will go through!

May be there are well defined credential types that are understood in a network and the verifier calls appropriate verification apis internally which is generally unlikely to be a get url .

--edit start.
get urls are possible if it is some sort of signed data is sent back which can Be verified by the np using signing pub key of the credential provider.

• edit end

Also if this verification api gives many attributes, would they include the validity dates and statuses.?

[venkatramanm]

Also I am thinking, there could be credential verification service provider(s), nps could make use off to verify credentials tossed around in the network.

Possibly by type of credential, there could be different service providers who integrate with the relevant verification api internally.

These providers could be on a different domain like ondc:credential or sorts.

[surendrasinghs]

Folks, this is an interesting discussion - thought of chiming in with a few thoughts.

1. Have you checked the W3C VC specification? It solves for many of the above use-cases i.e. Verification by any third-party (in this case, Consumer), or Presentation for a specific purpose (the example above of Export Norms and Licence varying across countries). Check W3C VC Core Data Model to understand this further.
2. I believe the current Credential schema in Beckn core is sufficient, and we would not need additional fields (e.g. Issued On/Valid From and Expired On) because the Context in a VC will provide that information.
3. We, the Sunbird RC community, had done a few webinars on the same - watch this & this. There are also VC Specs & Schema, Microservices, and some reference UIs available for anyone to use.

Happy to help take this forward.

@ravi-prakash-v thanks for bringing this to my notice.

[ravi-prakash-v]

Thanks @surendrasinghs! @nitinmish @venkatramanm do go through the above links and see if this suits your use cases. Secondly, it will be helpful if we can detail out one business use case, end-to-end.

@nitinmish the context that you provided

Each provider may have possibly numerous credentials associated that may vary from being a Badge, Certificates, Licenses etc to enhance the trust factor associated. It is possible that a provider may have multiple credentials associated and may like to send them in an array for buyer Apps to render on their side. Credentials will vary basis the requirement of a transactions. For example, export norms and licenses vary from country to country and a provider may like to send such certificates pertaining to a context, which in turn can be processed by a consumer App and rendered for a consumer to take a decision.

has multiple use cases inside it. Can you clearly detail out each use case before arriving at a problem statement. Preferably with a Persona. For example,

Use Case 1

1. MyMart is a store registered on a BPP on ONDC, who sells dairy products, fruits, and meat products.
2. MyMart has obtained certification from three agencies <Name of Agency 1>, <Name of Agency 2>, and <Name of Agency 3> for selling Dairy, Fruits and Meat products respectively.
3. Latha is a user on a BAP on ONDC who wants to buy grocery.
4. Latha searches for eggs, milk and mangoes on her app.
5. Immediately, she sees a list of products sold by various sellers on ONDC. One of them is MyMart
6. Against the MyMart search result, she sees a small button that says - View Creds.
7. She clicks on the link and sees a list of Certifications the seller has obtained.
8. She clicks on one of the certificates and is redirected to (somewhere) where she is able to verify the authenticity of the certificate.

Use Case 2

1. MyMart is a store registered on a BPP on ONDC, who sells dairy products, fruits, and meat products.
2. MyMart has obtained certification from three agencies <Name of Agency 1>, <Name of Agency 2>, and <Name of Agency 3> for selling Dairy, Fruits and Meat products respectively.
3. Latha is a user on a BAP on ONDC who wants to buy grocery.
4. Latha searches for eggs, milk and mangoes on her app.
5. Immediately, she sees a list of products sold by various sellers on ONDC. One of them is MyMart
6. Against the MyMart search result, she sees a small button that says - View Creds.
7. She clicks on the link and sees a list of Certifications the seller has obtained.
8. She clicks on one of the certificates and is redirected to (somewhere) where she sees that the certificate has expired.
9. She reports it on her app

@surendrasinghs do let me know if I'm going in the right direction with these use cases. I'm not very clear on what happens after the user clicks on a certificate. Feel free to update the use case. @nitinmish if you can create similar use cases for badges, licenses etc, that would help.

Secondly, @nitinmish can you also articulate the business problem that you want to solve here?
Currently the problem statement that you posted,

Currently, the Credentials reference in core protocol only captures three fields which in turn is referred as attribute creds against each provider. Licenses may have many facets and credentials section must capture additional attributes. Current structure of Credentials meta section is as follows:

does not capture why you need this; in other words, what business problem on ONDC you're trying to solve. The above problem statement should be a consequence of that.

[pramodkvarma]

@ravi-prakash-v beckn should not understand various VC schemas. Instead it should simply allow multiple VCs to be attached and transported using the protocol. Otherwise every VC schema change will have implications to beckn schema which is a no-no.

Please make sure these two are well unbundled and loosely coupled.