Re: Verifiable Text-based Claims

David,

I’m exploring a content layer atop an issuance layer. The issuance layer is the validity or existence of the digital resource, the TTL or minimum interval of availability of the digital resource. The content layer interval is the duration of intention of assertion of content, revocations or supersessions.

The solution has four fields:

1. issued -- the onset of the issuance layer

2. expires -- the expiration of the issuance layer, open-ended if omitted

3. contentIssued -- the onset of the content layer, default value if omitted is the onset of the issuance layer

4. contentExpires -- the expiration of the content layer, default value is open-ended if omitted


https://w3c-ccg.github.io/verifiable-news/sketchpad.html#issuance-layer-and-content-layer-intervals describes the ideas of issuance layer and content layer.

https://w3c-ccg.github.io/verifiable-news/sketchpad.html#temporary-revocations-and-supersessions indicates temporary revocations which support suspension and resumption.


Best regards,
Adam

From: David Chadwick<mailto:D.W.Chadwick@kent.ac.uk>
Sent: ‎Sunday‎, ‎September‎ ‎17‎, ‎2017 ‎3‎:‎03‎ ‎AM
To: Adam Sobieski<mailto:adamsobieski@hotmail.com>, public-credentials@w3.org<mailto:public-credentials@w3.org>

Hi Adam

Given the broad remit of your supersession, I would suggest the
following for consideration
1. supporting suspension and resumption
2. when a VC is superceded, the new VC points to a different revocation
URL than the superceded VC

regards

David

On 16/09/2017 19:37, Adam Sobieski wrote:
> David,
>
> Thank you. Supersession is described in more detail here:
> https://w3c-ccg.github.io/verifiable-news/sketchpad.html#supersession-of-statements .
> Though it differs from revocation, I’m thinking that, since supersession
> extends revocation, a supersession object could be at a URL
> indicated for a revocation object, providing additional information. If
> a system doesn’t process supersession, then it can process a
> supersession as a revocation, and, if a system does process
> supersession, then it obtains the additional information.
>
> Here is an updated version:
>
> {
>   "id":"https://example.com/users/1/revocations/ebfeb1f712ebc6f1/",
>   "type":["Revocation","Supersession"],
>   "issuer":"https://example.com/users/1/issuer/",
>   "issued":"2017-06-19T21:19:10Z",
>   "revoked":"https://example.com/facts/ebfeb1f712ebc6f1/",
>   "supersededBy":"https://example.com/facts/a3cc92841ac9c3f2/",
>   "reason":{
>     "id":"https://example.com/users/1/rationale/a3cc92841ac9c3f2/",
>     "type":"HTMLEmbeddedRationale"
>   },
>   "signature":{
>     "type":"LinkedDataSignature2017",
>     "created":"2017-06-19T21:19:10Z",
>     "creator":"https://example.com/users/1/keys/",
>     "nonce":"c0ae1c8e-c7e7-469f-b252-86e6a0e7387e",
>     "signatureValue":"BavEll0/I1zpYw8XNi1bgVg/sCneO4Jugez8RwDg/+MCR
>     VpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCuFibcC1wpsPRdW+g
>     GsutPTLzvueMWmFhwYmfIFpbBu95t501+rSLHIEuujM/+PXr9Cky6Ed+W3JT24="
>   }
> }
>
> I’m still considering whether the features and expressiveness are worth
> the additional complexity.
>
>
> Best regards,
> Adam
>
> *From:* David Chadwick <mailto:D.W.Chadwick@kent.ac.uk>
> *Sent:* ‎Saturday‎, ‎September‎ ‎16‎, ‎2017 ‎1‎:‎57‎ ‎PM
> *To:* Adam Sobieski <mailto:adamsobieski@hotmail.com>,
> public-credentials@w3.org <mailto:public-credentials@w3.org>
>
>
>
> On 15/09/2017 15:27, Adam Sobieski wrote:
>> David,
>>
>> I see your point. I was thinking about the special case of journalistic
>> retractions. I updated the example indicating a revocation object.
>>
>> I’m thinking that we can also use revocations for superseding
>> statements, which allows features including the updating of and the
>> moving/redirection of statements.
>
> This is conceptually something different from a revocation statement.
> Consequently I would suggest that the original statement is revoked and
> a new statement is issued.
>
> regards
>
> David
>
>>
>> {
>>   "id":"https://example.com/users/1/revocations/ebfeb1f712ebc6f1/",
>>   "type":"Revocation",
>>   "issuer":"https://example.com/users/1/issuer/",
>>   "issued":"2017-06-19T21:19:10Z",
>>   "revoked":"https://example.com/facts/ebfeb1f712ebc6f1/",
>>   "supersededBy": "https://example.com/facts/a3cc92841ac9c3f2/"
>>   "signature":{
>>     "type":"LinkedDataSignature2017",
>>     "created":"2017-06-19T21:19:10Z",
>>     "creator":"https://example.com/users/1/keys/",
>>     "nonce":"c0ae1c8e-c7e7-469f-b252-86e6a0e7387e",
>>     "signatureValue":"BavEll0/I1zpYw8XNi1bgVg/sCneO4Jugez8RwDg/+MCR
>>     VpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCuFibcC1wpsPRdW+g
>>     GsutPTLzvueMWmFhwYmfIFpbBu95t501+rSLHIEuujM/+PXr9Cky6Ed+W3JT24="
>>   }
>> }
>>
>>
>> Best regards,
>> Adam
>>
>> *From:* David Chadwick <mailto:D.W.Chadwick@kent.ac.uk>
>> *Sent:* ‎Friday‎, ‎September‎ ‎15‎, ‎2017 ‎5‎:‎51‎ ‎AM
>> *To:* Adam Sobieski <mailto:adamsobieski@hotmail.com>,
>> public-credentials@w3.org <mailto:public-credentials@w3.org>
>>
>> Hi Adam
>>
>> the revocation statement should not contain details of the VC that has
>> been revoked as this is privacy invasive. There are no ACLs on
>> revocation lists (usually). All it should contain is the ID of the VC
>> that has been revoked, signed by the issuer (in a similar way to an
>> X.509 CRL). In this was an inspector who has the VC, has the unique ID
>> and can therefore check if the VC was revoked or not
>>
>> regards
>>
>> David
>>
>> On 15/09/2017 02:52, Adam Sobieski wrote:
>>> David,
>>>
>>> Updated the sketchpad per your recommendation:
>>>
>>
> https://w3c-ccg.github.io/verifiable-news/sketchpad.html#revocation-of-statements .
>>>
>>>
>>> Best regards,
>>> Adam
>>>
>>> *From:* David Chadwick <mailto:D.W.Chadwick@kent.ac.uk>
>>> *Sent:* ‎Thursday‎, ‎September‎ ‎14‎, ‎2017 ‎6‎:‎33‎ ‎PM
>>> *To:* public-credentials@w3.org <mailto:public-credentials@w3.org>
>>>
>>> Hi Adam
>>>
>>> On 14/09/2017 02:50, Adam Sobieski wrote:
>>>> David,
>>>>
>>>> Thank you. At
>>>>
>>>
>>
> https://w3c-ccg.github.io/verifiable-news/sketchpad.html#http-based-revocation ,
>>>> I describe a system where Not found (404, 410) means revoked and Ok
>>>> (200) means not revoked. I see what you’re saying about Not found
>>>> meaning not revoked and Ok with a credential ID meaning revoked as well
>>>> as the feature of retrieving lists of revoked credentials. I think that
>>>> we should have both HTTP-based approaches. I updated the document with
>>>> these ideas.
>>>>
>>>
>>> In order to make the revocation more secure we placed a digitally signed
>>> CRL at the revoke URL. In this way a hacker is not able to hack the web
>>> site and get it to return OK with a message, because he does not have
>>> access to the issuer's private key
>>>
>>> regards
>>>
>>> David
>>>>
>>>> Best regards,
>>>> Adam
>>>>
>>>> *From:* David Chadwick <mailto:D.W.Chadwick@kent.ac.uk>
>>>> *Sent:* ‎Wednesday‎, ‎September‎ ‎13‎, ‎2017 ‎3‎:‎21‎ ‎PM
>>>> *To:* public-credentials@w3.org <mailto:public-credentials@w3.org>
>>>>
>>>> Hi Adam
>>>>
>>>> I notice that you are also including a revocation mechanism in your
>>>> claims. I produced an IETF draft 10 years ago which proposed something
>>>> very similar for X.509 certificates
>>>> ( See https://www.ietf.org/archive/id/draft-chadwick-webdav-00.txt).
>>>> Conceptually they are the same: the credential contains the URL where
>>>> the revocation information can be found. If Not found is returned the
>>>> credential has not been revoked, otherwise Ok is returned along with a
>>>> CRL of length 1 containing the ID of the revoked credential. My ID
>>>> contains other features as well, such as the ability to retrieve all the
>>>> revoked credentials of a particular issuer. You might wish to consider
>>>> this as well
>>>>
>>>> regards
>>>>
>>>> David
>>>>
>>>> On 12/09/2017 22:13, Adam Sobieski wrote:
>>>>> I’m exploring and sketching some ideas with regard to verifiable
>>>>> text-based claims.
>>>>>
>>>>> https://w3c-ccg.github.io/verifiable-news/sketchpad.html

>>>>>
>>>>> Questions, comments and suggestions welcomed.
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Adam Sobieski
>>>>>
>>>>
>>>