GS1's decentralized approach to resolving identifiers over HTTPS

From IIW

GS1’s Decentralized Approach to Resolving Identifiers Over HTTPS

Session: 10A

Convener: Phil Archer, Gena Morgan Paul Dietrich, & Melanie Nuce

Notes-taker(s): Gena Morgan & Orie Steele

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Slides are at General principles paper is at

GS1 DIgital Link standard makes the standard product Identifier - the “UPC” code web resolvable. Making it do more than go beep at the check out.

SSI / DIDs “not central point of issuance, no single point of failure”...but we can meet those requirements with persistent identifiers with centralized federation… centralized + delegation can work.

We can resolve identifiers with DNS / HTTPS… and it works today!

Bar codes are 40+ years old… they are trusted and used everywhere… its deeply embedded, its here to stay… we are trying to make those identifiers resolvable / dereferencable.

GS1 operates in lots of sectors / healthcare /automotive / construction and most known for retail.

GS1 is in 114 countries, truly global… GS1 has people in north korea :)

Bar Code -> URL -> URLs

How do we learn more about products in a structured way? _Using URLs!_

Location, Batch, Manufacturer, etc… the vocabulary for products can be embedded in URLS, and some of that information can be extracted without even being online.

What do we mean by “resolve”?

We want to be able to link to multiple types of information.

Any one thing, will have lots of associations… we can link to them all.

We can also query, not just resolve… using linkType parameter.

Can you give me patient information, a video, etc… the resolver will comply if it can.

You can also ask for all the links…

The structure of the JSON response is not standardized yet.

There will likely be a way to provide a signature on it.

Other companies can provide their own resolvers.

All the HTTP / DNS stuff works at the network level… so you don’t need to download a whole HTTP page to get all the links.

So what? How does this compare to did resolution?

You can take a bar code, and you can resolve that barcode to a number of things… b2b, b2c, or an e-wallet with credentials.

3rd Party Credentials for Organic, Gluten Free, etc…

Some claims have more weight when they come from a 3rd party, such as a certification body - not the first party brand.

Key points:
- We just use HTTPS… its massively implemented and supported… it works in web browsers.
Identifiers can be persistent as well… specs are persistent… web addresses can be persistent if you want them to be.
HTTP depends on DNS, but identifiers don’t.
We can say state our persistence policy, but humans will always be responsible for enforcing the policy.

GS1 doesn’t want to be the only resolver.

The GS1 Resolver Code is Apache2 on github, you can run your own… maybe on a cloud other than Azure.

The identifier is separate from the resolver…. the same identifier might resolve to different documents depending on the resolver…. this is a a feature defined in the standard… v2 is coming soon.

How do we make the use of VCs valuable?

How do we say a Product is Gluten Free as stated from a specific organization.

credential identifier is a URL.

credential type “NutritionalClaimCredential”

Example uses a regular HTTPs URLs.

VC Data Model does not require the use of DIDs! for Subjects, Holders or Issuers.

Credential Subject will be a GS1 Identifier.

GS1 uses machine readable vocabulary.

GS1 doesn’t need to use DIDs. Even if a verifiable credential (issuer) . COuld use if you wanted commitment to a credential at a moment in time and in a way that is “trustless”. Time based feature of this may be what is valuable.

DID controller determines what goes into a DID- so DID doc is augmented with commitment.

Should we use DIDs? How does it make it more (or less) secure than a URL as an identifier with a signature around the data block? Not clear that the complexity of DID resolution provides more security or trust t serving up the linked data from the resolvable product ID..

VC data model does not require came before the DID std. Trust system lies with DNS and domain and operator with HTTPS. (Orie - please help summarize what you just said :-))

DiD resolvers are no more secure than a DNS against attacks. Certain risks in DNS but any new technology still requires trust and the may be subjected to similar attacks

==Zoom Chat log ==

From Infominer to Everyone: 07:40 PM just add 3 letters at the end ‘ZKP’

From Infominer to Everyone: 07:49 PM this is great, happy to hear :)

From Eric Welton (Korsimoro) to Everyone: 07:53 PM

From Gena Morgan to Everyone: 07:56 PM so - in summary, the presentation of data from a particular source of that data can be signed (to ensure their identity is trusted) and we have trusted data from whomever the source may be. Is that correct? so we don't need DIDs for serving up supply chain data between trading partners and even consumers

From Me to Everyone: 07:57 PM That's my understanding, yes

From Eric Welton (Korsimoro) to Everyone: 07:58 PM i agree as well - there are some concerns around that -- orie might be able to speak clearly to them. it is not the sort of thing you can take with the same level of assurance as, for example, a public/private key pair are *pairs*

From Jace Hensley to Everyone: 07:58 PM The proofPurpose field of the proof object also tells you how to validate that proof using the resolved document for the keys

From Eric Welton (Korsimoro) to Everyone: 07:59 PM i wondered if you could say "pp.<method>" and then have a pp object in the DID-doc.... but I never worked out if that made sense or horribly broke things... thoughts?

From Jace Hensley to Everyone: 08:03 PM That’s kinda what the proofPurpose+verificationMethod fields do right? proofPurpose tells you where to look and verificationMethod tells you what to look for (what key to look for in the DID doc) Saying DID doc but it could be any controller doc