- From: Joe Andrieu <joe@joeandrieu.com>
- Date: Sun, 17 Sep 2017 11:58:10 -0700
- To: public-credentials@w3.org
- Message-Id: <1505674690.2368556.1108991160.5BAC873D@webmail.messagingengine.com>
David,
Regarding point 2, best practice suggests that the revocation URL is not
claim specific. That would create a privacy leak as accessing the URL
would imply use of the claim.
The expectation is that revocation registries return a list of
potentially many revoked claims, thus preventing correlation by access.
In this case, there is no need for a different revocation URL.
https://example.com/revocations works fine for both new and old.
That said, I see now that Adam's proposal is, in fact, claim specific.
In practice, I believe with will be far more likely to be issuer
specific, and for large issuers, potentially segmented by domains.
Adam, while I agree it would be useful to ensure that revocations are
signed, the revocation URL should not be specific to the claim. It also
should not contain any of the claim content and, IMO, should also not
include the ID of the issuer. Only inspector-verifiers with the original
claim should be able to check the signature on the revocation. It isn't
anybody else's business.
Exposing the claim content and even the id of the issuer is a privacy
leak. A good revocation list should be able to be published completely
in public, e.g., on IRC or IPFS without even the possibility of someone
without possession of a given claim being able to learn anything about
that claim. All the list needs is the ID of revoked claims and,
potentially, for redundancy, a hash of each, signed by the original
issuer (as per the claim's authenticationCredential).
Regarding David's first point, I agree. Simply removing a claim from a
revocation list is a simple approach to resumption. Suspension then is a
matter of temporary revocation. It may be interesting to allow for a tag
in a revocation list to indicate suspension v revocation, but that's
speculation. I don't believe there is yet a consensus around a proposed
revocation list format. Thanks for putting something concrete forward.
Your idea of supersession could easily be handled in a revocation list.
I like that idea. It's fairly elegant and not much harder to support
than revocation. There is a privacy leak, however, so it should be used
with caution. It shouldn't be assumed that someone in possession of a
revoked claim has any reason to know there is a replacement. Presumably,
it should be up to the holder to secure the new claim and present it to
the inspector-verifier. Nevertheless, it's an elegant hack that might
have valuable uses.
-j
On Sun, Sep 17, 2017, at 12:03 AM, David Chadwick wrote:
> 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
>>>>>>
>>>>>
>>>>
>
--
Joe Andrieu, PMP
joe@joeandrieu.com
+1(805)705-8651
http://blog.joeandrieu.com
Received on Sunday, 17 September 2017 18:58:35 UTC