Skip to content
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

Merged
merged 57 commits into from
Apr 18, 2023
Merged

Conversation

ottonomy
Copy link
Contributor

@ottonomy ottonomy commented Dec 16, 2022

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:

  • Check all 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
  • Check all spec references using [[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...
  • Check all links to OB and CLR specs to make sure they point to the final published location of these specs (rather than github.io pages preview locations, etc. It's important to be able to deep-link into these specs to specific headings, because they are long.
  • Apply consistent capitalization for headings. Currently roughly: H2 and Above Appear in Title Case and H3 and below appear in sentence case.
  • Apply desired consistent formatting for code snippets using <pre>
  • Add link(s) to reference implementations (1EdTech member-only)
  • Add links to conformance and certification suite at production location

@ottonomy
Copy link
Contributor Author

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 .prettierrc.json into the impl folder here just so that it would format on save in VS Code, but .editorconfig or .prettierrc stuff should probably be done at the repo level rather than just within this one folder. Once we're ready for merge of these markdown files, this local config file could be removed so that we can address the topic of code style and consistency as a separate effort.

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
Copy link
Contributor

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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

"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.
Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Member

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

Copy link
Contributor

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.

@ottonomy ottonomy marked this pull request as draft January 10, 2023 16:36
Comment on lines +1 to +8
{
"trailingComma": "es5",
"semi": false,
"singleQuote": true,
"printWidth": 80,
"tabWidth": 4,
"proseWrap": "always"
}
Copy link
Contributor Author

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.

Copy link
Contributor

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
Copy link
Contributor Author

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

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
Copy link
Member

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?

Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Member

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!

@ottonomy ottonomy marked this pull request as ready for review February 27, 2023 17:18
@ottonomy
Copy link
Contributor Author

ottonomy commented Mar 8, 2023

Thanks to @xaviaracil for checking off most of those little formatting todos!

@xaviaracil
Copy link
Collaborator

Merging. Will track the addition of the reference implementation link in a separate issue

@xaviaracil xaviaracil merged commit e5c25da into develop Apr 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants