W3C home > Mailing lists > Public > public-credentials@w3.org > March 2015

Credential or just a Statement?

From: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
Date: Thu, 05 Mar 2015 15:43:37 +0100
Message-ID: <54F86B99.3090905@wwelves.org>
To: W3C Credentials Community Group <public-credentials@w3.org>
CC: James M Snell <jasnell@gmail.com>, Sandro Hawke <sandro@w3.org>
Hello,

Following conversation we started during our last telecon, where I
struggled a little to see where we draw line between a Credential and
just a simple Statement.

BTW, I see Merged Credentials Example also relevant to this conversation
https://lists.w3.org/Archives/Public/public-credentials/2015Feb/0027.html --
thanks Dave!

Looking at EXAMPLE1 in current draft
http://opencreds.org/specs/source/identity-credentials/#a-typical-identity

I see name, governmentID, email, mobileNumber, birthdate,
shippingAddress and all the other 'attributes' of 'top level' object as
just simple Statements


Then I see *credential* property with example of PassportCredential, it
has signature and creator other than Bob. In its *claim* object it has
name, birthdate, governmentId just as in 'top level' object.

In a way we also have just simple Statements but made by *someone else*
(another Agent).

This gives me impression that Credential must include some element of
verification / trust. I could request someone shippingAddress together
with set of credentials which *back* / *prove* it e.g. issued by school,
electricity provider etc.

Lets look at two other examples: Membership and Attendance

I could, publish statements:

(ignoring httpRange-14 and /foo - 303 -> /foo/ )

GET /perpetual-tripper/ HTTP/1.1
Host: wwelves.org
Accept: application/ld+json

====================================

HTTP/1.1 200 OK
...
Content-Type: application/ld+json

{
  "@context": "https://w3id.org/identity/v1",
  "id": "https://wwelves.org/perpetual-tripper",
  "type": "schema:Person",
  "name": "elf Pavlik",
  "schema:memberOf": [ "https://www.w3.org" ],
  "schema:attendeeIn": [ "https://www.w3.org/2014/11/TPAC" ]
}

*Claiming* that I have membership in W3C and attended in TPAC 2014.

In intuitive 'hosted credential' approach. I could dereference both
objects and search for inverse properties *schema:memeber* &
*schema:attendee*. IMO very simple and obvious convention!

GET / HTTP/1.1
Host: www.w3.org
Accept: application/ld+json

====================================

HTTP/1.1 200 OK
...
Content-Type: application/ld+json

{
  "@context": "https://w3id.org/identity/v1",
  "id": "https://www.w3.org",
  "type": "schema:Organization",
  "name": "World Wide Web Consortium (W3C)",
  "schema:member": [ "https://wwelves.org/perpetual-tripper" ],
  "schema:event": [ "https://www.w3.org/2014/11/TPAC" ]
}


GET /2014/11/TPAC/ HTTP/1.1
Host: www.w3.org
Accept: application/ld+json

====================================

HTTP/1.1 200 OK
...
Content-Type: application/ld+json
{
  "@context": "https://w3id.org/identity/v1",
  "id": "https://www.w3.org/2014/11/TPAC",
  "type": "schema:Event",
  "name": "TPAC 2014",
  "schema:attendee": [ "https://wwelves.org/perpetual-tripper" ],
  "schema:organizer": [ "https://www.w3.org" ]
}

For signed approach W3C could issue for me appropriate credentials

GET /perpetual-tripper/ HTTP/1.1
Host: wwelves.org
Accept: application/ld+json

====================================

HTTP/1.1 200 OK
...
Content-Type: application/ld+json

{
  "@context": "https://w3id.org/identity/v1",
  "id": "https://wwelves.org/perpetual-tripper",
  "type": "schema:Person",
  "name": "elf Pavlik",
  "schema:memberOf": [ "https://www.w3.org" ],
  "schema:attendeeIn": [ "https://www.w3.org/2014/11/TPAC" ],
  "credential": [{
    "id": "https://www.w3.org/credentials/3732",
    "type": "MembershipCredential",
    "claim": {
      "id": "https://wwelves.org/perpetual-tripper",
      "schema:memberOf": "https://www.w3.org"
    },
    "signature": {
       "type": "GraphSignature2012",
       "creator": "https://www.w3.org/keys/27",
       "signature": "3780eyfh3q0fhhfiq3q9f8ahsidfhf29rhaish"
    }
  },
  {
    "id": "https://www.w3.org/credentials/3738",
    "type": "AttendanceCredential",
    "claim": {
      "id": "https://wwelves.org/perpetual-tripper",
      "schema:attendeeIn": "https://www.w3.org/2014/11/TPAC"
    },
    "signature": {
       "type": "GraphSignature2012",
       "creator": "https://www.w3.org/keys/27",
       "signature": "89afua9fjaldkfjaofajfoaidfakdjaodafp9a"
    }
  }
 ]
}

Actually we will need such MembeshipCredential and AttendanceCredential
on in our recent experiments with Portable Linked Profiles :)
http://www.open-steps.org/introducing-the-new-open-knowledge-directory-with-plp-profiles/

I also see that in Social WG we will need a way for verifying likes,
comments, reviews etc. AFAIK IndieWeb community takes such intuitive
'hosted credential' approach to verify such claims. Still for >2000
likes it may not scale very well :P Simple PKI + signed credentials can
help with addressing this issue...

Cheers!


Received on Thursday, 5 March 2015 14:44:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:23 UTC