Re: Credential or just a Statement?

+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'

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!
>
>