merge: '3-implement-aif-support' into 'main'

Resolve "Implement AIF support"

Closes #3

See merge request namib-master/libraries/dcaf-rs!2

Author: falko17

CHANGELOG.md

@@ -0,0 +1,55 @@
+# Changelog
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [0.2.0] --- 2022-04-05
+This release focuses on introducing [AIF] and [libdcaf]-support.
+
+### Added
+- Support for scopes using the 
+  [Authorization Information Format (AIF) for ACE](https://datatracker.ietf.org/doc/html/draft-ietf-ace-aif).
+  For this purpose, the following types have been added:
+    - `AifEncodedScope`, representing an AIF-encoded scope (surprise)
+    - `AifEncodedScopeElement`, a single element in an AIF-encoded scope
+    - `AifRestMethodSet`, encoding a set of REST methods
+- Support for scopes used by the [libdcaf] implementation 
+  (a variant of AIF-encoded scopes).
+
+### Fixed
+- Binary-encoded scopes are now properly serialized.
+- Some incorrect documentation regarding scopes has been corrected.
+
+## [0.1.0] --- 2022-04-02
+As this is the first release, lots of basic functionality has been setup.
+For more extensive documentation, consult the 
+[crate-level documentation](https://docs.rs/dcaf).
+
+### Added
+- CBOR de-/serializable model of the ACE-OAuth framework has been added:
+    - Binary- and text-encoded scopes
+    - Access token requests and responses
+    - Authorization server request creation hints
+    - Error responses
+    - Various smaller types (`AceProfile`, `GrantType`, `ProofOfPossessionKey`, `TokenType`...)
+    - Use `serialize_into` or `deserialize_from` to serialize and deserialize these types.
+- Methods to create and work with access tokens:
+    - `encrypt_access_token`
+    - `decrypt_access_token`
+    - `sign_access_token`
+    - `verify_access_token`
+    - `get_token_headers` (to extract headers from an opaque token)
+- Related: Various COSE Cipher traits intended for users to implement,
+  used in the above methods for cryptographic operations:
+    - `CoseCipherCommon` (to set headers specific to the cipher)
+    - `CoseEncrypt0Cipher`
+    - `CoseVerify1Cipher`
+    - `CoseMac0Cipher`
+- Constants describing CBOR abbreviations of various ACE-OAuth fields
+- `no_std` support
+
+[0.1.0]: https://github.com/namib-project/dcaf-rs/releases/tag/v0.1.0
+[0.2.0]: https://github.com/namib-project/dcaf-rs/compare/v0.1.0...v0.2.0
+[AIF]: https://datatracker.ietf.org/doc/html/draft-ietf-ace-aif
+[libdcaf]: https://gitlab.informatik.uni-bremen.de/DCAF/dcaf

Cargo.toml

@@ -1,7 +1,7 @@
 [package]
 name = "dcaf"
 description = "An implementation of the ACE-OAuth framework"
-version = "0.1.0"
+version = "0.2.0"
 edition = "2021"
 authors = ["Falko Galperin <falko1@uni-bremen.de>"]
 rust-version = "1.58"
@@ -27,6 +27,7 @@ erased-serde = { version = "^0.3.18", default-features = false, features = ["all
 derive_builder = { version = "^0.10.2", default-features = false }
 strum = { version = "^0.24", default-features = false, features = ["derive"] }
 strum_macros = { version = "^0.24", default-features = false }
+bitflags = "1.3"
 
 [dev-dependencies]
 hex = { version = "^0.4.3" }

README.md

@@ -40,12 +40,12 @@ while `alloc` is still needed, this crate offers
 ## Usage
 ```toml
 [dependencies]
-dcaf = { version = "^0.1.0" }
+dcaf = { version = "^0.2.0" }
 ```
 Or, if you plan to use this crate in a `no_std` environment:
 ```toml
 [dependencies]
-dcaf = { version = "^0.1.0", default-features = false }
+dcaf = { version = "^0.2.0", default-features = false }
 ```
 
 ## Example
@@ -58,7 +58,7 @@ quickly introduce both of these here.
 [For example](https://www.ietf.org/archive/id/draft-ietf-ace-oauth-authz-46.html#figure-7), say you (the client) want to
 request an access token from an Authorization Server. For this, you'd need to create an `AccessTokenRequest`, which has
 to include at least a
-`client_id`. We'll also specify an audience, a scope (using `TextEncodedScope`---note that binary-encoded scopes would
+`client_id`. We'll also specify an audience, a scope (using `TextEncodedScope`---note that binary-encoded scopes or AIF-encoded scopes would
 also work), as well as a
 `ProofOfPossessionKey` (the key the access token should be bound to) in the `req_cnf` field.
 
@@ -173,6 +173,9 @@ When implementing any of the specific COSE ciphers, you'll also need to implemen
 `CoseCipherCommon` trait, which can be used to set headers specific to your COSE cipher
 (e.g. the used algorithm).
 
+## Changelog
+You can find a list of changes in [CHANGELOG.md](CHANGELOG.md).
+
 ## License
 
 Licensed under either of

src/common/cbor_map/mod.rs

@@ -276,24 +276,13 @@ pub trait ToCborMap: private::Sealed {
     }
 }
 
-/// Decodes the given specific `scope` of type `T` into the general [`Scope`] type.
+/// Decodes the given specific `scope` into the general [`Scope`] type.
 ///
 /// # Errors
 /// - If `scope` is not a valid scope.
-pub(crate) fn decode_scope<T, S>(scope: T) -> Result<Scope, TryFromCborMapError>
-where
-    S: TryFrom<T>,
-    Scope: From<S>,
-    S::Error: Display,
-{
-    match S::try_from(scope) {
-        Ok(scope) => Ok(Scope::from(scope)),
-        Err(e) => {
-            return Err(TryFromCborMapError::from_message(format!(
-                "couldn't decode scope: {e}"
-            )));
-        }
-    }
+pub(crate) fn decode_scope(scope: Value) -> Result<Scope, TryFromCborMapError> {
+    Scope::try_from(scope)
+        .map_err(|e| TryFromCborMapError::from_message(format!("couldn't decode scope: {e}")))
 }
 
 /// Decodes the given `number` Integer into a more specific integer of type `T`.