Re: State, not Identity-based Credential Use Cases?

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?
>
>
>
>