v0.12.1

What's Changed

• Client attestation updates by @dtsiflit in #110
• Request header case insensitive parsing by @dtsiflit in #112

Full Changelog: v0.12.0...v0.12.1

v0.12.0

What's Changed

• Updated refresh token support by @dtsiflit in #109
• Attestation-based client authentication support by @dtsiflit in #107

Breaking changes

• The protocol AuthorizationServerClientType functions requestAccessTokenAuthFlow and requestAccessTokenPreAuthFlow now include an IssuanceRefreshToken in their return value Result.
• OpenId4VCIConfig client is now a Client instead of a ClientId.
  • Using client: .public(id: "your-client-id") will replicate the exisiting functionality.
• Issuer authorizeWithPreAuthorizationCode client is now a Client instead of a ClientId.
• Issuer authorizeWithPreAuthorizationCode client is now a Client instead of a ClientId.
• AuthorizationServerClient client is now a Client instead of a ClientId.
• AuthorizationServerClient requestAccessTokenPreAuthFlow client is now a Client instead of a ClientId.
• AuthorizationServerClient preAuthCodeFlow client is now a Client instead of a ClientId.
• OpenId4VCIConfig now accepts a DPoPConstructorType.

Full Changelog: v0.11.0...v0.12.0

v0.11.0

What's Changed

• Dpop nonce support during authorization by @dtsiflit in #106

Breaking changes

The AuthorizationCodeRetrieved struct now includes a new field dpopNonce: Nonce?.

Full Changelog: v0.10.1...v0.11.0

v0.10.1

What's Changed

• Made display logo property public by @dtsiflit in #105

Full Changelog: v0.10.0...v0.10.1

v0.10.0

What's Changed

• Feature/dpop nonce by @dtsiflit in #100

Breaking changes

The following protocols and their implementations have been updated to use a nonce (dpop nonce) and a boolean (retry) in their signatures:

• IssuanceRequesterType
• IssuerType
• AuthorizationServerClientType
• NotifyIssuerType

The IssuanceRequesterType protocol now accepts an additional retry boolean parameter.

Important Notes on dpop Nonce Handling

These changes are relevant if your authorization or resource server responds with a DPoP nonce. For more details, refer to the RFC9449 (https://datatracker.ietf.org/doc/html/rfc9449#name-resource-server-provided-no, https://datatracker.ietf.org/doc/html/rfc9449#name-authorization-server-provid) specification on authorization server-provided nonce and resource server-provided nonce.

Examples of how this is implemented can be found in:

testWithOfferSdJwtDPoP()
testWithOfferMultipleSdJwtDPoP()

Note:
Using Regular Bearer Tokens
If you are not utilizing DPoP but instead rely on regular bearer tokens:
Set dpopnonce to nil.
Set retry to false in all cases.
This ensures compatibility without adopting DPoP-specific functionality.

Full Changelog: v0.9.3...v0.10.0

v0.9.3

What's Changed

• Async signer updates by @dtsiflit in #103

Full Changelog: v0.9.2...v0.9.3

v0.9.2

What's Changed

• Parse claims from sd-jwt-vc metadata by @dtsiflit in #102

Full Changelog: v0.9.1...v0.9.2

v0.9.1

What's Changed

• Feature/draft 14 by @dtsiflit in #98
• Updated swifty json by @dtsiflit in #101

Breaking changes

• The Issuer now accepts a binding key array instead of a single binding key. If you want to use the Issuer in a similar backwards compatible way to Draft 13, pass a binding key array with a single value.

• The binding key JWK case now accepts an array of SigningKeyProxys. If you want to use the Issuer in a similar backwards compatible way to Draft 13, pass a binding key array with a single value containing .secKey(_your_key_).

• Draft 14 supports the issuance of a document while providing multiple proofs. If an issuance is successful, the credential will be issued and located in a variable of type:

public enum Credential: Codable {
  case string(String)
  case json(JSON)
}

If a single credential is issued, its value will be located in string(String). Multiple credentials will be located in json(JSON) as an array.

• CWT has been removed.
• Batch credential issuance has been removed.

The examples contained in the test target provide usages for all the above scenarios.

Full Changelog: v0.8.0...v0.9.0

v0.9.0

What's Changed

• Feature/draft 14 by @dtsiflit in #98

Breaking changes

• The Issuer now accepts a binding key array instead of a single binding key. If you want to use the Issuer in a similar backwards compatible way to Draft 13, pass a binding key array with a single value.

• The binding key JWK case now accepts an array of SigningKeyProxys. If you want to use the Issuer in a similar backwards compatible way to Draft 13, pass a binding key array with a single value containing .secKey(_your_key_).

• Draft 14 supports the issuance of a document while providing multiple proofs. If an issuance is successful, the credential will be issued and located in a variable of type:

public enum Credential: Codable {
  case string(String)
  case json(JSON)
}

If a single credential is issued, its value will be located in string(String). Multiple credentials will be located in json(JSON) as an array.

• CWT has been removed.
• Batch credential issuance has been removed.

The examples contained in the test target provide usages for all the above scenarios.

Full Changelog: v0.8.0...v0.9.0

v0.8.0

What's Changed

• Updated signing logic by @dtsiflit in #99

Breaking Changes

• The BindingKey jwk case now accepts SigningKeyProxy instead of a SecKey as an associated value.
  This is a breaking change and to continue using keys please use .secKey(your_key) instead of just your_key when creating a BindingKey. Several examples here

Full Changelog: v0.7.2...v0.8.0