- From: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
- Date: Sat, 07 Mar 2015 18:29:15 +0100
- To: eric.korb@accreditrust.com
- CC: public-credentials@w3.org
- Message-ID: <54FB356B.2030407@wwelves.org>
On 03/07/2015 06:16 PM, Eric Korb wrote: > +1 Elf, very good. Here is signed example using our TrueCred framework > based on the specification: > > https://dev.truecred.com/i/erickorb/badges/1.1.28.2 > > Or curl 'https://dev.truecred.com/i/erickorb/badges/1.1.28.2' 1. it has only 1 triple in *claim* "claim": { "about": "https://dev.truecred.com/i/erickorb" } looks like it will not work with Merged Credentials Example https://lists.w3.org/Archives/Public/public-credentials/2015Feb/0027.html 2. it uses "owner" "owner": "https://dev.truecred.com/i/erickorb" i find no mention of "owner"in * Identity Credentials 1.0 - http://opencreds.org/specs/source/identity-credentials/ * Open Badges Technical Specification http://specification.openbadges.org/ only in https://w3id.org/openbadges/v1 > > To see simple example of the verification process, click "Verify" in this > web page: > https://dev.truecred.com/tools?badge=https:%2F%2Fdev.truecred.com%2Fi%2Ferickorb%2Fbadges%2F1.1.28.2 > > *"* > >> 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 Saturday, 7 March 2015 17:29:29 UTC