Re: Credential or just a Statement?

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