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

On 12 February 2015 at 21:05, 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?
>

I think this can probably be done already, but you'd likely need to write
some code for the particular workflow.  The data points in the form
including the token from the credenitaling service would need to match the
data stored.  So a that point you'd either have proof of those credentials,
or you'd send them somewhere to be further processed.  If you had the
actual fields in mind in JSON, maybe we could work out which parts to put
in the body and which in the signature.