In section 4.1 we already state “RPs SHOULD ignore verified_claims containing a trust framework id they don’t understand” (which is a fine strategy by me)
In Section 220.127.116.11 and with regard to evidence/document/type we state “The OP MAY use other than the predefined values in which case the RPs will either be unable to process the assertion, just store this value for audit purposes, or apply bespoken business logic to it”, but I think this text is too descriptive and not normative enough. I’d go for “RPs SHOULD ignore document types they don’t understand”.
There’s no guidance at the moment for unknown evidence/type or evidence/method. We have to deal with that.
Marcos: What do you refer to when you say “private [registry] values”? Extensions not “sanctioned” by this WG?
Another thought: Require extensions to publish a JSON schema.
Re “Private values”: Yes. A space to experiment, with the recommendation to use collision-resistant names by e.g. prefixing them with URIs.
Re “JSON schema”: Good point. Since the content of “verification” element is completely dependant on the value of “trust_framework” in the registry, each new “trust_framework” should be accompanied by a formal definition of the “verification” structure.
Tony suggested to use namespaces instead of registries. We can set up a web page to list the know identifiers. We need to decide what the best representation will be: HTML, md, … wiki.