Update README and set version to v0.0.1.

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "uidc"
-version = "0.1.0"
+version = "0.0.1"
 edition = "2021"
 
 # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

LICENSE

@@ -0,0 +1,30 @@
+Copyright (c) 2023 Kestrel Yarrow. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification,
+are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+and/or other materials provided with the distribution.
+
+3. All advertising materials mentioning features or use of this software must
+display the following acknowledgement:
+This product includes software developed by the the organization.
+
+4. Neither the name of the copyright holder nor the names of its contributors
+may be used to endorse or promote products derived from this software without
+specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY COPYRIGHT HOLDER "AS IS" AND ANY EXPRESS OR IMPLIED
+WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
+AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL COPYRIGHT
+HOLDER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
+OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
+GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+DAMAGE.

README.md

@@ -1,11 +1,11 @@
 ### uidc, a lightweight OpenID Connect server ###
 
-uidc is a lightweight OpenID Connect server, implementing the [OpenID Connect
+uidc is a lightweight OpenID Connect (OIDC) server, implementing the [OpenID Connect
 Core][openid-spec] specification. It's designed as a replacement for
 heavyweight systems like [Keycloak][keycloak] when you want to have SSO without
 a dedicated machine running it, for example on personal or small-scale
-infrastructure.
-
+infrastructure. Since it supports OIDC, it also functions perfectly well as an
+OAuth2 provider.
 
 [openid-spec]: https://openid.net/specs/openid-connect-core-1_0.html
 [keycloak]: https://keycloak.org/
@@ -91,8 +91,13 @@ uidc implements a simple role-based authentication schema. it works as follows:
 - _roles_ are further grouped into _scopes_
 
 When authentication tokens (or refresh tokens!) are created, a list of _scopes_
-is requested. All roles in the intersection of the target user's groups and the
-client's available roles will then be attached to that token.
+is requested. The resulting set of roles in the authentication token is the following:
+
+> attached\_roles(user\_groups) ∩ attached\_roles(given\_scopes)
+
+That is, a role is only included in the authentication token if it is both a)
+requested during the token grant, and b) available to the user through a group
+they are a member of.
 
 For illustration, let's create three roles, put them into two groups, and
 assign each group to a single user. We'll also put all the roles into a scope
@@ -127,7 +132,7 @@ $UIDC scope attach-role example-scope roleB
 $UIDC scope attach-role example-scope roleC
 ```
 
-Now, if we generate some authentication tokens for `user1` and `user2` and peek at the JWT claims:
+Now, if we generate some authentication tokens for `user1` and `user2` and peek at the JWT claims, we'll see the roles split between the two users:
 
 ```shell
 $UIDC token generate-auth --client example-client --username user1 --scopes example-scope \
@@ -163,4 +168,41 @@ $UIDC token generate-auth --client example-client --username user2 --scopes exam
 }
 ```
 
+#### Provider configuration ####
+
+Each realm gets its own set of token endpoints, available at
+`https://uidc-base-url/<realm>/.well-known/openid-configuration`. An example
+configuration might look something like the following:
+
+```json
+{
+  "authorization_endpoint": "https://base-url/primary/oidc/authorize",
+  "id_token_signing_alg_values_supported": [
+    "EdDSA"
+  ],
+  "issuer": "https://base-url/primary",
+  "jwks_uri": "https://base-url/primary/oidc/jwks",
+  "response_types_supported": [
+    "code",
+    "id_token",
+    "token id_token"
+  ],
+  "subject_types_supported": [
+    "public"
+  ],
+  "token_endpoint": "https://base-url/primary/oidc/token",
+  "token_endpoint_auth_signing_alg_values_supported": [
+    "EdDSA"
+  ]
+}
+```
+
+### Implementation and licensing details ###
+
+Core components of uidc:
+
+* `schema`: database schema types for type-safe use of SQLite via [microrm](https://crates.io/crates/microrm)
+* `server`: server runtime
+* `*_management`: implementations of manipulation helpers for CLI and/or REST API interfaces
 
+uidc is licensed under a 4-clause BSD license.

src/server/oidc.rs

@@ -201,8 +201,7 @@ async fn jwks(request: Request) -> tide::Result<tide::Response> {
     let keyinfo = qi
         .get()
         .by(schema::Key::Realm, &realm)
-        .all()
-        .expect("couldn't query db")
+        .all()?
         .into_iter()
         .map(|key| {
             let kpair = ring::signature::Ed25519KeyPair::from_pkcs8(&key.keydata)