Re: Signed HTTP Exchanges use case

Hi Phil,

I don't see how a signed exchange is going to give you what you want here.

If I understand your scenario, the client has two things that are trustworthy: the (low entropy) number from the product, and a root CA store.  It also has an address of a resolver, but we don't necessarily trust that.

A signed exchange can be used by the operator of a site (any site) to produce information about its own origin.  But here the thing that the app is using is the combination of the resolver address and the number.  None of that establishes any expectation about the identity of the manufacturer.

If the identity of the manufacturer were known, then you might be able to do something about attesting to the relationship between a given page (this is recipes for this device) and the device itself, anchored in the identity of the manufacturer.

With the information you have, nothing can be signed except for content that the resolver controls.  And you've stated that the resolver is not necessarily trusted in this interaction.

--Martin

On Thu, Feb 14, 2019, at 03:47, Phil Archer wrote:
> 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 Thursday, 14 February 2019 00:03:26 UTC