Signed HTTP Exchanges use case

Dear Jeffrey,

My colleagues at GS1 and I have been looking at your Signed HTTP
Exchanges work which looks like a good fit for a use case we have - but
I need to do a sanity check, please. Here's a simple example of the kind
of use case we're tackling:

I scan a barcode on a product using a mobile phone app.

The app adds the scanned number (we call it the GTIN) into a template
URL https://example.com/gtin/{gtin}.

example.com is a server that conforms to a GS1 standard (that we're
writing at the moment) and redirects the request to a resource on the Web.

Given that anyone can build and operate a GS1 conformant resolver, we
need a method of distinguishing between a redirection link authorised by
the product manufacturer and any other link a resolver might offer.

Adding just a little complexity, actually we want resolvers to offer
multiple links with link relation types like "recipeWebsite" and
"instructionManual" - and those links will be exposed in an HTTP Link
header.

It looks as if your Internet Draft provides exactly the kind of thing we
need - the ability for a brand to sign that HTTP exchange, saying "yes,
we authorised these links" - even though they're not the ones operating
the resolver.

If it is the case that your I-D is a suitable method for achieving this,
would you consider adding a further use case to that effect in Appendix A?

Thanks

Phil

--
Phil Archer
Director, Web Solutions, GS1
https://www.gs1.org

http://philarcher.org
+44 (0)7887 767755
@philarcher1
Skype: philarcher

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.

Received on Wednesday, 13 February 2019 16:47:37 UTC