-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TwitterVerification VerifiableCredential semantics #13
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The credential is initialized here:
tzprofiles/worker/src/lib.rs
Lines 41 to 68 in c9ac5db
It has the tweet verification put in here:
tzprofiles/worker/src/lib.rs
Lines 127 to 142 in c9ac5db
I think this would result in a credential (before signing) like this:
Putting that through JSON-LD Playground results in the following N-Quads:
Table view:
This shows several URIs under
schema.org
, such ashttp://schema.org/tweetId
, which are not meaningful.These occur because the
schema.org
JSON-LD context file sets@vocab
("default vocabulary) which means undefined terms automatically get prefixed. This is good for preserving information which would otherwise not be included in the signing input, and maybe other reasons, but its use here results in bad URIs (404s on schema.org, unclear semantics) which could reduce interoperability. For this reason I would recommend not using"https://schema.org/"
in context arrays, unless you are sure of the effect.Removing
https://schema.org/
from the credential's context results in an error because the terms previously defined become undefined. The only one we are using that comes fromschema.org
issameAs
. That term can be defined on its own:Next there are the new Twitter verification related terms. We should decide what these terms will expand to. The way
schema.org
does it is to basically give each term its own page. Other namespaces have a single main URI under which the terms use fragments. These don't have to be resolvable as JSON-LD files for verification, but they should be, and they should also work as web pages so that people can look at them and reference them. I will assume below that we would use separate pages undertzprofiles.com
. For examples of JSON-LD context files you can find several inssi
: https://github.com/spruceid/ssi/tree/main/contexts/The terms needing definition are
TwitterVerification
,TwitterVerificationPublicTweet
,handle
,timestamp
,tweetId
. A simple way to proceed would be to define all these:This may be improved by changing timestamp to be an XML Datetime string which is a more common way to represent a timestamp in JSON-LD:
But I'm not sure if that interferes with other usage that may require the timestamp to be an number.
Another improvement would be to scope the term definitions by the type. e.g. define
handle
,timestamp
andtweetId
underTwitterVerificationPublicTweet
:There may be better semantics possible for these terms; I'm not sure.
Resulting N-Quads:
Table view:
The text was updated successfully, but these errors were encountered: