1EdTech/openbadges-specification

Allow for other Evidence properties

Closed this issue · 5 comments

David-Chadwick commented

My understanding is that the current schema requires the Evidence property type to be set to 'Evidence' whereas, according to the VC DM it is an array and the type can be any URI. Could you relax your requirements so that an array of Evidences can be added.

In our particular project we are adding an Evidence property to indicate the strength of authentication that the issuer undertook when authenticating the user, before issuing the VC to them. We would like to be assured that this will not violate the latest Open Badges specification.

ottonomy commented

This sounds like a potentially good suggestion to consider. In order to implement it, we also must be careful not to lose sight of the value of predictability when it comes to something with such a wide range of options as Evidence. Keeping relying party (verifier) complexity low through carefully limiting issuer-side options is a design goal of the specification, and your suggestion here to relax a limitation cuts against that design goal.

We could potentially do it with clarification that evidence types not identified by the spec should not be expected to be understandable to a relying party without prior out-of-band arrangement. However, is it possible just to make the proposed evidence compatible with the spec?

@David-Chadwick can you provide an example of such an evidence object that would accomplish this use case and describe if it implements a specific other standard that would prevent it from being augmented to be in accordance with the required properties of the Evidence class? (the only requirement is that there be a 'type' field whose value is an Array that contains the item "Evidence")

David-Chadwick commented
ottonomy commented

I don't think the above answered the question of whether the proposed Evidence item could be modified to meet the requirements of the Open Badges spec:

"evidence":[
              {
                 "type":["https://eur-lex.europa.eu/eli/reg/2014/910/oj", "Evidence"],
                 "description":"this is the URI of the eIDASv1 regulation. It will need updating to the URI of eIDASv2 when it is available",
                 "loa":"low|substantial|high"
              },
              {
                 "type":["https://doi.org/10.6028/NIST.SP.800-63-3", "Evidence"],
                 "description":"this is the URI of the NIST Special Publication 800-63 scheme",
                 "aal":"refers to the authentication process, has values 1, 2 or 3",
                 "ial":"refers to the identity proofing process, has values 1,2 or 3",
                 "fal":"(optional) refers to the strength of an assertion in a federated environment, used to communicate authentication and attribute information. Has values 1,2 or 3"
              }
           ],

This seems like a simple approach that would not require any change from the spec. If that could be implemented by issuers, then we could close this issue.

David-Chadwick commented

As I read the Open Badge specification of Evidence, then only the type parameter is mandatory and all the additional properties are optional. Thus the "evidence" that we are using above already appears to conform to the Open Badge Evidence spec, in that it is missing some of your optional properties and has extended your definition to include additional ones. Is this a correct interpretation of your Evidence specification?

xaviaracil commented

It is, only the type attribute is mandatory, and it can be extended with your own attributes. The only requirement is that one of the items in the type array MUST be Evidence.

Your interpretation is correct. Closing this issue, then