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