There is a long prose description of how the flow might work. Should this be there? @gkellogg and @msporny , please chime in.

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)

See https://lists.w3.org/Archives/Public/spec-prod/2015JulSep/0020.html.

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.

Thoughts @gkellogg, @burnburn, @bsletten ?

• 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?

Documentation

• Create proposal for Credentials Task Force in Web Payments IG (@msporny)
• Refine proposal for Credentials Task Force in Web Payments IG
• Create proposal for Fast Track Linked Data Platform WG (LD-Patch and RDF Dataset Normalization)
• Create comparison between Identity Credentials and OpenID Connect
• Create comparison between Identity Credentials and SAML
• Create comparison between Linked Data Signatures and JOSE
• Create Linked Data Key Management specification
• Create comparison between cant.py and Aidan Hogan's algorithms

Standards Implementation Foundation

• Board of Directors for Standards Implementation Foundation (@erickorb)
• Advisory Committee for Standards Implementation Foundation (@erickorb)

Outreach

• Demo Identity Credentials to MIT CSAIL research group (@msporny)
• Ask Wendy Seltzer who needs to be consulted about the groups plans
• Ask Brad Hill how he'd solve the problem
• Ask Jeff Hodges how he'd solve the problem
• Ask Harry Halpin how he'd solve the problem
• Ask Dick Hardt how he'd solve the problem

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!

• https://www.youtube.com/channel/UCnaA8lQHipp7D6nedkpdE0A

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.