W3C home > Mailing lists > Public > public-credentials@w3.org > September 2017

Re: Verifiable Text-based Claims

From: David Chadwick <D.W.Chadwick@kent.ac.uk>
Date: Mon, 18 Sep 2017 18:28:25 +0100
To: public-credentials@w3.org
Message-ID: <8959c21e-0732-4840-2438-4c7596199cff@kent.ac.uk>
Joe you have an inconsistency in your arguments.

First you imply that the issuer does not want to support privacy so will
monitor which inspectors retrieve single revocations from unique URLs,
then you say that issuers will support as much privacy as they wish by
having CRLs as big as they choose. But using your first argument they
will clearly support CRLs as small as possible, preferably single ones.
But if they do support privacy then they will *not* monitor who
retrieves single CRLs so these are perfectly acceptable. Either way
single CRLs fit the requirements of both issuer and verifier.

Secondly you say the inspector cannot manage the VCs. But since the
inspector is carrying all the risk, then it is entirely up to the
inspector to decide whether to download CRLs or not. Or to demand that
the user fetches a fresh VC each time so that a CRL is not needed. So it
is the inspector that effectively manages the VCs and CRLs that it will
accept. Much more so than the issuer, who will issue VCs when requested
by the user.

regards

David

On 18/09/2017 16:14, Joe Andrieu wrote:
> 
> On Mon, Sep 18, 2017, at 12:49 AM, David Chadwick wrote:
>> On 17/09/2017 19:58, Joe Andrieu wrote:
>>
>>     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.
>>
>>
>> Accepted.
>>
>> However, CRLs can grow to massive sizes (as the DoD PKI knows only too
>> well) and forcing inspectors to download a complete list can be very
>> inefficient.
>>
>> Thus a scheme such as
>>
>> https://example.com/revocations/uniqueCRL
>>
>> would allow an inspector to either download the entire list at
>> revocations or individual ones at uniqueCRL
>>
>>
>>     The expectation is that revocation registries return a list of
>>     potentially many revoked claims, thus preventing correlation by
>>     access.
>>
>>
>> So one has to balance the correlation by access (which can be avoided by
>> using TOR) versus the inefficiency of downloading potentially millions
>> of revocations.
> 
> The issuer can always limit the # of claims they assign to any
> revocation list in direct correlation to how much privacy they want to
> support. You're only as anonymous as the number of people you can be
> mistaken for. There is a broad range between "all claims ever issued by
> the issuer" and "a single claim". That spectrum is fully manageable to
> achieve whatever balance the issuer wants: a hundred claims, a million, one.
> 
> Issuers can also simply issue short-lived claims with near term expiry
> dates, placing the burden primarily on the holder to keep credentials
> refreshed, so the issuer doesn't need to check revocation at all.
> 
> It isn't at all manageable by the inspector-verifier, but it's not their
> credential to manage.
> 
> -j
> 
>>
>> David
>>
>>     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>
>>         <mailto: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>
>>         <mailto: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>
>>                   <mailto: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>
>>                       <mailto: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 <mailto:joe@joeandrieu.com>
>>     <mailto:joe@joeandrieu.com>
>>     +1(805)705-8651
>>     http://blog.joeandrieu.com
>>
>>
> 
> --
> Joe Andrieu, PMP
> joe@joeandrieu.com <mailto:joe@joeandrieu.com>
> +1(805)705-8651
> http://blog.joeandrieu.com
> 
Received on Monday, 18 September 2017 17:28:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:13 UTC