- From: Kim Hamilton <kimdhamilton@gmail.com>
- Date: Thu, 21 Nov 2019 17:49:21 -0800
- To: "Michael Herman (Parallelspace)" <mwherman@parallelspace.net>
- Cc: Credentials Community Group <public-credentials@w3.org>, Phil Archer <phil.archer@gs1.org>
- Message-ID: <CAFmmOzcysPF2cB5i0bVKQ4sT3h7XotJKSDQfacFzvHyR4HG71g@mail.gmail.com>
Phil - I’m interested in a couple of topics you touched on. > it would be really to have a running example throughout - that would make the whole thing easier to understand I'd say. This is a great readability suggestion. To clarify resolution, do you mean running examples using a specific did method (e.g btcr, which is a good candidate because it is simple and not tied to a vendor)? Not necessarily getting into (in this doc) implementation details of how btcr achieves it, but something along the lines of: "for example, given this btcr input, you'd expect this output, and see more details here" Second, it sounds like an interesting parallel you mention with GTIN. And +1 for exploring usability implications that you call out. My motive: while I haven’t paid attention to DID resolution progress in a while, the idea of matrix parameters and possible developer usability implications (because they seem less standard) is something I keep meaning to revisit. Yours sounds like a great forcing function for this discussion. On Mon, Nov 18, 2019 at 1:27 PM Michael Herman (Parallelspace) < mwherman@parallelspace.net> wrote: > Phil, I like your examples. We need more of them. > > > > Although the results are formatted in HTML (to make them easier to read > for a retail consumer), each *linkType* is actually the name of a > Credential (Credential Type) associated with the Subject's (product's) > Digital Identifier (e.g. gtin/09506000134352) that, in turn, serves as the > underlying data for building the web page – that is, each linkType or > Credential represents different (possibly overlapping) collections of > Claims (name-value pairs) for the Subject product (and its web page). > > > > We need more of these real-life non-fungble entities (NFE) examples. > > > > Best regards, > > Michael Herman > > Self-Sovereign Blockchain Architect > > Hyperonomy Digital Identity Lab > > Parallelspace Corporation > > > > [image: Trusted Digital Web Certificate 0.1] > > > > > > > > -----Original Message----- > From: Phil Archer <phil.archer@gs1.org> > Sent: November 18, 2019 7:37 AM > To: Credentials Community Group <public-credentials@w3.org> > Subject: GS1's work on identifiers, resolvers and resources > > > > TL;DR - concepts of resolving identifiers to multiple possible > destinations is being actively discussed elsewhere as well as here and > there *may* be room for some commonality of approach with DID resolution. > There's likely to be some ISO work in this area soon. > > > > Dear all, > > > > I finally (finally!) got around to reading the resolution spec which is > very interesting if difficult to read. As a suggestion, because you're > writing something abstract that only becomes real for a given DID Method, > it would be really to have a running example throughout - that would make > the whole thing easier to understand I'd say. > > > > Anyway... > > > > GS1 has been issuing identifiers for 45 years, the best known of which is > what we nowadays call the GTIN but you may know it as the EAN/UPC or simply > 'barcode.' My work is primarily about making those identifiers resolvable > on the Web so that things like this will work: > > > > https://id.gs1.org/gtin/09506000134352 > > > > which is a concrete example of the more general > > > > https://{resolver}/{idType}/{idValue} > > > > We can add things like batch numbers, serial numbers, expiry dates and > more but that'll do for now. > > > > If you resolve a GTIN (product barcode) and you're a consumer, you're > probably after something like a product information page - which is what > you get if you click that first link. As that's a food item, you might want > to find something like a recipe idea for that product > > > > https://id.gs1.org/gtin/09506000134352?linkType=recipeInfo > > > > or product sustainability information > > > > https://id.gs1.org/gtin/09506000134352?linkType=productSustainabilityInfo > > > > If you're a developer, you might want all the links available for a given > item, which is what you get if you click > > > > https://id.gs1.org/gtin/09506000134352?linkType=all > > > > (conneg gives you that in HTML or JSON, with JSON-LD coming soon). > > > > So there's a difference with DIDs: in the GS1 context, the default that > makes sense is to pass you on to 'something directly useful' rather than a > document that contains links to things that might be useful but you can get > the machine readable list of stuff if you want. In contrast, DIDs give you > the machine readable document by default and redirect you somewhere else if > you really want it. > > > > But there's a lot of common thinking there, no? > > > > Btw, I'll make a comment in GH about the notion of a resolver description > file - we have such a thing > > > > https://id.gs1.org/.well-known/gs1resolver > > > > and we have things like one resolver redirecting to another if it doesn't > have info about the identified item, and we're thinking that, in future, we > might define a format for a small data file that can help you find the > right resolver for your identifier without going through multiple HTTP > redirects. > > > > GS1 is working with HTTP, so the thinking is all Webby and Link Data. > > Try this, for example > > > > curl -I https://id.gs1.org/gtin/09506000134352 > > HTTP/1.1 307 Temporary Redirect > > Date: Mon, 18 Nov 2019 12:22:21 GMT > > Server: Apache/2.4.38 (Debian) > > X-Powered-By: PHP/7.3.11 > > Link: <https://dalgiardino.com/risotto-rice-with-mushrooms/>; rel="pip"; > type="text/html"; hreflang="en"; title="Product information page", < > https://dalgiardino.com/mushroom-squash-risotto/>; rel="recipeinfo"; > type="text/html"; hreflang="en"; title="Recipe website", < > https://dalgiardino.com/where-to-buy/>; rel="hasretailers"; > type="text/html"; hreflang="en"; title="Retailers", < > https://dalgiardino.com/about/>; rel="productsustainabilityinfo"; > type="text/html"; hreflang="en"; title="sustainability and recycling" > > Location: https://dalgiardino.com/risotto-rice-with-mushrooms/ > > Access-Control-Allow-Origin: * > > Access-Control-Allow-Methods: HEAD, GET, OPTIONS > > Access-Control-Expose-Headers: Link, Content-Length > > Cache-Control: max-age=0, no-cache, no-store, must-revalidate > > Content-Type: text/html; charset=UTF-8 > > > > Note the HTTP Link Header that has all the available links in it, > including what we can linkTypes (@rel values), titles and hreflang > attributes. > > > > We can add more than just the linkType in the query params, we can also > have a 'context' which can be anything, but location is a typical use case > (tell me about this product in the UK cf. this product in France) and we > support Accept and Accept-Language HTTP request headers. That's a bunch of > parameters that form a matrix of possible redirections :-) > > > > Related conversations are going on elsewhere that I think are likely to > lead to some standardisation work at ISO before long. From GS1's POV, that > will be important and I hope ideas around resolvers, defaults, > redirections, link types etc. will be part of that discussion - but it's > too early to offer any concrete info as yet. > > > > Chapter and verse on what we call GS1 Digital Link is in a draft standard > at > https://www.gs1.org/sites/default/files/docs/gsmp/gs1_digital_link_1.1_comrev_version_786.pdf > . > > Chapter 8 is about resolvers. > > > > Enough for one email. > > > > I'm happy to talk more about any of this if people want, but equally happy > to keep quiet. > > > > Cheers > > > > Phil > > > > -- > > Phil Archer > > Director, Web Solutions, GS1 > > https://www.gs1.org > > > > https://philarcher.org > > +44 (0)7887 767755 > > @philarcher1 > > Skype: philarcher > > A word on abbreviations I sometimes use in email: > > https://philarcher.org/diary/2019/emailabbreviations/ > > > > CONFIDENTIALITY / DISCLAIMER: The contents of this e-mail are > confidential and are not to be regarded as a contractual offer or > acceptance from GS1 (registered in Belgium). > > If you are not the addressee, or if this has been copied or sent to you in > error, you must not use data herein for any purpose, you must delete it, > and should inform the sender. > > GS1 disclaims liability for accuracy or completeness, and opinions > expressed are those of the author alone. > > GS1 may monitor communications. > > Third party rights acknowledged. > > (c) 2016. > > > > >
Attachments
- image/jpeg attachment: image001.jpg
Received on Friday, 22 November 2019 01:49:35 UTC