- From: Eric Korb <eric.korb@accreditrust.com>
- Date: Thu, 12 Feb 2015 15:33:08 -0500
- Cc: W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAMX+RnBGYuDMcAj36YgihNqZRFw8_jQFPcwSMrKXGwD+MCu-kw@mail.gmail.com>
Like the idea, not the name. How about "location-based credentials"? Also, who/what would sign them? Private keys in the devices? Eric On Thu, Feb 12, 2015 at 3:05 PM, Brian Sletten <brian.sletten@gmail.com> wrote: > I am working on a talk in which, among other things, I am generating > JSON-LD for sensor data and serving it up via an embedded HTTP server. > Sensor data includes things like GPS location, ambient temperature/humidity > levels, etc. As I submit this data to another service, I started wondering > how to avoid someone lying about their location. The process has gotten me > wondering about another use of credentials that I haven't seen much > discussion on. We generally are thinking about long-term, identity-based > credentials (clearly the dominant use), but I am wondering if the group > thinks it would be useful to also consider shorter term, state-based > credentials not necessarily tied to an identity. > > I can imagine a large number of scenarios, but here are a couple: > > 1) Demonstrating that you are within a particular geographic area. > Obviously checking the reverse geolocation of an IP address is a form of > this, but I am thinking of something more verifiable. Anyone can lie about > where they are, but if there is a local credentialing service on a > particular Wifi network or you are within range of a low energy Bluetooth > beacon, we could assert a geographic location credential which could be > useful for access to services, resources, marketing opportunities, etc. > > 2) Demonstrating that you own a token. I can imagine a variety of uses for > something like this. Games, workflow management, etc. Imagine something > like Ingress (https://www.ingress.com) but with a capture-the-flag > component. Or, in a distributed workflow (inventory management, sales > channel fulfillment, etc.), if there are a variety of participants (or > participating systems), you could require that only one at a time can take > action on a common resource. Clearly, this is possible w/o an open standard > credential, but I wonder if it might be easier to build something like that > around standards in loosely-coupled ways. There would obviously have to be > another credentialing service that asserts the current token ownership in a > distributed and portable way. > > I don't think this necessarily changes anything about the existing focus, > I just wonder if there is value in considering some less conventional uses > of machine-processable credential standards for scenarios like this. > Basically, might we consider state-based credentials rather than only > identity-based credentials? > > > >
Received on Thursday, 12 February 2015 20:34:01 UTC