- 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