search

google / physical-web

The Physical Web: walk up and use anything
http://physical-web.org
Apache License 2.0
5.99k stars 665 forks source link

Utilize blockchain identities to enable more advanced Physical Web interactions #634

Open csuwildcat opened 8 years ago

csuwildcat commented 8 years ago

Using the blockchain as an identity system for people and objects, we can create trusted relationships between users, Physical Web items, and their aggregate owners/providers. I detail various aspects of the system in my recent blog post: http://www.backalleycoder.com/2016/04/14/the-web-beyond-how-blockchain-identity-will-transform-our-world/

How would this apply to the Physical Web?

Assume: Users have blockchain identities (people), devices have blockchain identities (beacons), aggregate device providers have blockchain identities (for example: retail store chain)

A user notices a device is available via the OS/Agent detection interface. The user interfaces with the device through the OS/Agent UI. The OS/Agent at some point could ask three things:

  1. "Do you want to remember this device and be alerted to its presence when you are near?" -- This permission level allows a person to more easily be reminded that a 'favorite' device was in their area.
  2. "Do you want to remember this device and allow just this device to push you content?" --- This permission level allows a person to not only have awareness of the device the second or third time around, but also will allow them to receive push content from this and only this device.
  3. "Do you want to remember this device and allow the owner of it to push you content through all their Physical Web enabled objects?" --- This permission level allows a person to not only have awareness of the device in the future, and to receive push content from that device, but also to receive push content from all devices that are verified as being owned by this device's owning identity.

    How does this work on the tech level?

All of this is driven by user/object-owned identities that are referenced via the global blockchain. If a device has an identity attached to it, the user can sign a permission allowance for that device to their identity. If the device has an owner whose identity has many more devices signed to it, the user can choose to sign that device owner's identity to their own with a permission that accepts content from all devices that are signed to the owner's identity.

There will soon be APIs that enable these types of permissioned relationships between blockchain identities of users and devices capable of supporting the permission loop.

scottjenson commented 8 years ago

This is great! Thanks for writing this up. There is a lot here so please excuse the 'blockchain 101' type questions here. I expect others have them as well. I assume there are obvious answers to these so please bear with me:

1) The blockchain is getting a bad rep recently about scalability. is this issue being addressed with recent updates? 2) It seems like a lot to have everyone in a basic transation (people, beacons, domains) all have blockchain identities. Could we phase this in by having some beacons support this with some domains? 3) I'm not sure I understand the data flow to figure this out. Have you done rough transaction counts/bandwidth estimates to figure out what would be required for each beacon? 4) Could much of this transaction bandwidth still be done through our proxy service to cache results? 5) Or am I missing the point? (i.e. this could all be done entirely on the client and there be no server at all?

csuwildcat commented 8 years ago

@scottjenson I am clear to talk in depth about the system we're building (as it will be open source), but it may be quite verbose and a bit early for us to put out there on Github. Perhaps we can meet to go over it in detail?

rochforp commented 8 years ago

@csuwildcat I'd love to see some of the conversation on here... but I'm sure it's an extensive discussion. Hope to hear a little more about this.

csuwildcat commented 8 years ago

@rochforp well, let me try to answer @scottjenson's questions without getting to far into the weeds or being too simplistic:

1) The scalability issues with Bitcoin itself are being worked out by Core devs, and in terms of raw blockchain transaction times, I wouldn't worry about the long-term. Specific to identity, those raw transaction limitations really don't apply. In 99+% of use-cases you will not need to touch the blockchain at all to update identity data, so the speed is effectively real-time for CRUD and other operations.

2) For this to work for beacons, the user would need a blockchain identity, and the owner of the beacon(s) would need an identity. I stated earlier that beacons could have identities too, and they can, but that is not required to unlock the benefits/features I laid out. For example:

Now there are a couple ways you can go:

  1. You can add a field/property to beacon pings that Retailer Foo can use to pass a blockchain ID along with the content URL, which the OS/UA can in turn use to: ensure the content URL is from the matching, well-known blockchain identity's specified beacon content sources, and check Retailer Foo's blockchain identity for attestations from reputable third-party blockchain identities, which adds another layer of verification that they are a good actor.
  2. A cooler system: in addition to the content sources Retailer Foo allows via their blockchain identity's settings, they can also specify coordinates and 3D data about the locations they claim to own (which can be paired with verifiable attestations of authenticity). With these two pieces of information, the OS/UA can determine if the user is in one of these locations, and use the blockchain identity associated with the location to determine what beacon content pings are truly from the owner/custodian of the location, and which are not. In this case, the location could be a Retailer Foo store, wherein 99/100 beacons are good, but there is one malicious beacon an attacker has placed. The malicious one is not referring to a content URL the location's owning blockchain identity has allowed, thus it is rejected.

3) As I talked about in response to question 2 above, you don't need to impact the UX flow much at all from the beacon <--> user point of view.

4) Yes, identity data can be indexed and cached for faster reference, lowering bandwidth consumption, etc.

5) Much of this you could cache, but in certain cases, you'd want access to fresh versions of an identity's associated data.

saifrais commented 8 years ago

@csuwild: Blockchain identities have the potential to become the UUID for the Eddystone-URL. But, it would be great to have @scottjensen and team's opinion on the application of these identities in alleviating the privacy risks highlighted in the Web bluetooth use case draft against beacons (push notifying based on a previous approvals). Currently, as far as my limited knowledge goes, the Web Bluetooth draft suggests privacy concerns in allowing websites to scan for beacons. If the PWS can extend its services to 'this' handshake, we can open up the Web Bluetooth API to scanning for already authenticated beacons!

scottjenson commented 8 years ago

There's a lot implied in that last comment, most it off topic for this thread. I think blockchain is the core focus here and we can take the conversations two important ways.

  1. How would this work in principle so that we're all on board with the advantages and clear understanding of how the tech would work?
  2. How could we roll it out given it would most likely start with only partial adoption?

I'm not against talking about WebBluetooth in any way, it's just a separate topic that has a better place to discuss it. Let's sort how how blockchain works in principle with the Physical Web, THEN apply it to other issues as there are likely many.

I don't at all wish to push you away, I just think the 'Is WebBluetooth secure?" question is a complex one and discussing it here (without any of the WebBluetooth experts around to chime in) doesn't seem fruitful.

csuwildcat commented 8 years ago

Sorry for the radio silence for the last few days, I have been preparing for my trip out to NYC.

@saifrais I do agree there are many possible applications of the blockchain identity system we are working on, and I feel we can help alleviate the issue you cited, but initially we should probably focus on what we can do without requiring browsers and the W3C to adopt this identity system as a standard. I don't say that because I don't want it to be standardized - eventually I do - I simply believe that Scott is right to focus on first delivering value that can be had without that lengthy process, then building upon it as a proof point.

@scottjenson I would be happy to sit down with you and others after I return to talk through the use cases and flows we can enable. Let me know what works for you; hopefully we can post the findings here in this thread so interested folks like @saifrais can stay current with the state of things.

saifrais commented 8 years ago

Thanks @csuwildcat ..will be looking forward to it! @scottjenson : I guess 'crawling before walking' is always the right progression to any discussion :). My reason for jumping the gun was that the Physical Web and Web Bluetooth are (I believe) intended to seamlessly integrate with each other...one requisite for achieving this is that rules governing BOTH frameworks should be consistent. Use-cases, like push notifications and class authorization for a set of beacons, as articulated by @csuwildcat are where we all envision the physical web experience...but similar use cases are being articulated as 'issues' in the Web Bluetooth Use case draft (specifically 2.1.6 ->3.1.6 A..link below): [https://webbluetoothcg.github.io/web-bluetooth/use-cases.html#risk_class_pairing_data_leak]

But...I am sure the question can wait for an appropriate time!

scottjenson commented 8 years ago

Well, while we're waiting around for @csuwildcat to return, why not discuss it a bit more? ;)

This is especially true as I think you are getting to a core issue about how we're thinking about the Physical Web. It is a part of the "web stack" and gets most of it's power because it is 'just a part of the web' with the many layers of the web on top of it. We can build amazing demos using web sockets for example and those web sockets have no idea that the Physical Web is there: they are just two layers of the web that build upon each other.

Whenever I've talked to folks from WebBluetooth, one of the key points we discuss is that the two should have some separation, i.e. one should exist without the other. That is why for example, the WebBluetooth API has a call to Find nearby devices, which is clearly a parallel scanner to the one in the Physical Web. That parallelism, in my mind, is very important as it keeps the two layers from getting too intertwined.

However, your point is valid, in that if we do authentication with blockchain, it should be done uniformly between the Physical Web and WebBlueooth. But I'd claim it would go much further up the stack as well and not be limited to just these two technologies. If it really is a form of user auth, it should be used everywhere. This is a cool vision and a very very big one. I'm not at all against it, just saying this is WAY beyond just PW and WBT.

csuwildcat commented 8 years ago

@scottjenson hey there, back in town. I talked with the folks in our org and it sounds like they're open to us collaborating together directly - even hacking on the Physical Web code to integrate the blockchain identity hooks we've talked about. Would you want to hold a hackfest-type gathering where MS folks and Google folks worked side-by-side to make it happen?

scottjenson commented 8 years ago

This sounds very interesting. We are 'hair on fire' getting ready for GoogleIO next week (two Physical Web talks!) but let me float a few emails around. I'm just managing expectations that it'll be hard to move quickly over the next week.

csuwildcat commented 8 years ago

No problem with it taking a while; we won't have the system stood up until mid-June, so no rush. I just figured we could get the ball rolling now because the logistics of such a collaboration might take time. (Google and Microsoft building a consumer platform together - somewhere a fat lady is singing on a flying pig) On May 10, 2016 6:45 AM, "scottjenson" notifications@github.com wrote:

This sounds very interesting. We are 'hair on fire' getting ready for GoogleIO next week (two Physical Web talks!) but let me float a few emails around. I'm just managing expectations that it'll be hard to move quickly over the next week.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/google/physical-web/issues/634#issuecomment-218161241

scottjenson commented 8 years ago

Well, I don't want to get pedantic (and I assume you'll agree) but this can't be a "Google/Microsoft consumer platform". It should be an open web platform that we are kicking off to be shared with others. If this is tied to any one company's server, it's a no go. Again, I assume that's not a problem as this is bitcoin. But just to be extra clear, is this going to be a microsoft specific product server over bitcoin?

csuwildcat commented 8 years ago

@scottjenson yeah, I just meant that in terms of these two companies working together, not as the scope of who it was for or should be involved (remember, I worked at Mozilla for 5 years, so I very much want this to be an open, unencumbered platform)

The package/server that drives the system runs on top of the public, open blockchain, and it is 100% open source. Of course Microsoft will eventually build apps and services on top of it, but that's downstream and separate from the actual identity system.

jiceorange commented 8 years ago

Sorry if I am re-opening an old thread. @csuwildcat, what is the connection between the Microsoft Identity project that you described and this Physical Web project (which seems to be mostly Google supported). Are you collaborating?

Digging a bit deeper, I found links on Microsoft Research to this project as well.