opencreds / website Goto Github PK
View Code? Open in Web Editor NEWCOMMUNITY: The W3C Credentials Community Group website.
Home Page: https://opencreds.org/
License: Creative Commons Zero v1.0 Universal
COMMUNITY: The W3C Credentials Community Group website.
Home Page: https://opencreds.org/
License: Creative Commons Zero v1.0 Universal
https://github.com/opencreds/website/blob/master/specs/source/capabilities/index.html
If we can get a public goal-list/specific todo list we can start collaborating on this document (read: I can be useful).
I am available to sit down and talk to people to figure out what that should be.
Several early verifiable claims prototypes have added evidence about the claims that they have made. As these are already common need, should we specifically labeled as evidence, or be in their own section.
We need to consider where do issuers place "evidence" about the claims they have made. In the "Claims about Subject" section? or in the "Claim Set Metadata", or possibly in either place depending on the issuers trust of the evidence?
Right now, there's a manual process of creating a textual description of a use case UML and using PlantUML to create an SVG. Future needs require making such diagrams accessible.
(from @halindrome)
The mechanism should be able to be used via OpenID, OpenID Connect, and possibly both versions of OAuth. This section should elaborate how one can provide pointers to the identity assertion URL using those methods.
There are a lot of terms. For the sake of our readers, we need to use them consistently. And we should use as few unique ones as possible! I propose that we use these:
issuer - the entity that issues the credential.
holder - the entity that the credential is about, and who "holds" onto it.
consumer - the entity that needs to receive and analyze a credential.
Let's avoid terms like "recipient" - that has a flow feel to it and will change depending on how the data is flowing.
3.2 says of type:
This is a sequence of types, or classes, of which this data set is a member. As an Identity, at a minimum the class "Identity" must be the first value in the sequence. Additional application-specific values are permitted in the sequence.
Not all abstract representations can maintain type order (e.g., JSON-LD/RDF. In any case, this seems like a should, but it's not clear why this is an important aspect of the model. Consider "set of" instead of "sequence of".
signature
If a signature is based on an LinkdedDataSignature algorithm, doesn't this mean that every representation must be reducible to RDF? How does this jive with more free-form formats (e.g., XML/JSON)? How do you extract a signature fro WebIDL?
While the credential-based login mechanism below relies on an email provider to be the identity provider, a distributed identity mechanism using Telehash or some other Kademlia-based Distributed Hash Table algorithm could be utilized to allow any identity provider to vouch for any email address. This would result in two advantages over Persona. The first is that a centralized infrastructure for email address to identity provider mapping wouldn't be necessary. The second is that any identity provider could vouch for any email address. The details of this proposal can be found here: A Proposal for Credential-based Login.
The motivation section and/or the requirements section of this item should be reworked so they are not so similar. The requirement should be more assertive, and the motivation can be conversational. The motivation should cite more than one vector of motive. Also there should be an additional example (use case).
@msporny you videos would fit website very well!
Is there an existing working proof of concept around this new proposed standard ?
If not, can we gather a group of programming volunteer to put up an experimental software / website ?
Thx,
Costin
Currently the "id:" = "URI"
is described as a unique value for the claim that you can index, but it is also a place you can check to see if that specific claim is revoked.
However, there are cases (in particular did:btc), the issuer id can be revoked as a whole and all the claims from that issuer, but not individual claims issued by that issuer.
I'm not sure about using the id for double duty like this. Instead, I suspect that we should do is have a specific revocation check service tag rather than coercing both functions into id.
Another argument for a separate tag for this is that revocation is complicated. Is the issuer saying the claim valid at some point in the past but is now is not true, or that it made a mistake and it was never true? or that the issuer itself is invalid?
I also think it is possible what should happen if you try to resolve the id, it should just return the claim, which may be UPDATED with new expiration dates.
It's arguable that having a PUT or DELETE mechanism is useful. Both can be highly destructive and providing a common way to delete identities may be a bad thing if one experiences a security breach. In many cases, the identity document wouldn't be deleted, just merely marked as deleted in order to undelete it in the event of a mistake.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.