-
Notifications
You must be signed in to change notification settings - Fork 68
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
Work in Progress: Implementation Guide #501
Conversation
I was having some trouble with the markdown formatter built into the Atom text editor that I was previously using, and on another project I found that Prettier did a fantastic job with markdown. In commit 1d87e92 I put a |
in the coming years as the consumer technology landscape and open source | ||
libraries develop. | ||
|
||
The OB 3.0 and CLR 2.0 specifications make no normative requirements strictly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this section is really nicely put after our recent discussions
proceeds. Implementers are encouraged to join the 1EdTech community and discuss | ||
how we can further improve our implementations and guidance together. | ||
|
||
### Selecting recipient and issuer identifiers, such as DID methods |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A similar section to this may be helpful for crypto algorithms?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a cryptography expert. I sketched out such a section in commit 0b3f6e3 that can start the conversation.
ob_v3p0/impl/conformance.md
Outdated
"Issuer", "Displayer", "Host" in one spot, and then Service Consumer (Read), | ||
Service Consumer (Write), Service Provider (Read), Service Provider (Write), and | ||
it hasn't yet incorporated the idea of "issuer only" certification that was | ||
referenced in recent meetings. Follow up and make consistent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may be captured in the todo, but would be helpful to incorporate VC terminology such as Issuer and Holder into the below bullets.
- Endorsement | ||
- Re-issue a <= 3.0 Badge to a 3.0 Badge | ||
- Authorization to Issue Given by Creator to Issuer | ||
- Revocation of an Issued Credential |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd recommend removing Revocation of an Issued Credential unless we are mentioning how revocation would work in the base spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a note about how the importance of the use cases and how revocation might be normatively covered in a future version of the spec in commit 232fba0. That's probably the optimal balance--I know some readers are really going to want to see something about revocation in here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Historically it's been an important use-case and I tend to agree people new to this would find a mention of it helpful
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Section 9.1 references a new revocation status solution:
If the credentialStatus property is present, and the type of the CredentialStatus object is "1EdTechRevocationList", determine if the OpenBadgeCredential has been revoked as shown in 1EdTech Revocation List Status Method.
{ | ||
"trailingComma": "es5", | ||
"semi": false, | ||
"singleQuote": true, | ||
"printWidth": 80, | ||
"tabWidth": 4, | ||
"proseWrap": "always" | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note this .prettierrc.json
will be removed before the final pull request. As a separate issue, a .editorconfig
or similar may be added to the repository, consistently with 1EdTech architect recommendations for all next-generation 1EdTech specs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...begin spaces vs tabs argument?
@@ -0,0 +1 @@ | |||
## Getting Help |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding instructions here assigned to @xaviaracil
ob_v3p0/impl/getting-started.md
Outdated
format. See | ||
[Dereferencing the Public Key](https://1edtech.github.io/openbadges-specification/ob_v3p0.html#dereference) | ||
- When a client requests `Accept: */*` or `application/html`, an HTML | ||
representation of the Achievement should be presented. This should express |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this have a reference to conformance requirements?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it has ever been required or marked as "SHOULD" at the spec level to do this sort of content negotiation. Maybe a topic for the workgroup to consider, but I at least like this mentioned at the impl guide level.
- Endorsement | ||
- Re-issue a <= 3.0 Badge to a 3.0 Badge | ||
- Authorization to Issue Given by Creator to Issuer | ||
- Revocation of an Issued Credential |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Historically it's been an important use-case and I tend to agree people new to this would find a mention of it helpful
resulting in a DID document. It relies on the DNS registration of a domain | ||
holder, but many DIDs may be associated with any one domain or subdomain. | ||
|
||
Technically, this set of DID methods whose use is commonly observed among early |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A fair warning/notice to future implementers!
Style and wording updates
Thanks to @xaviaracil for checking off most of those little formatting todos! |
Merging. Will track the addition of the reference implementation link in a separate issue |
Work in progress, do not merge. However, a PR provides a nice place to collect comments and discussion, where we can reference specific text.
TODO List:
backtick-enclosed
quoted terms for consistent application of the pattern. Use backticks (for<code>
presentation of terms) for specific references to classes named in specifications. Do not use them for plain-english descriptions of the general concepts. e.g.Achievement
is a class defined by the specs to represent the idea of an achievement. @xaviaracil[[OR-11]]
spec references. Generally use a reference with a name link the first time the spec is referred to in a section/subsection, and use the proper name without further linking after. e.g.OneRoster [[OR-11]] is great. OneRoster lets institutions...
H2 and Above Appear in Title Case
andH3 and below appear in sentence case
.<pre>