- 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