Currently, we only expect a AccountService to provide a stable accountId and an optional user-visible userId for all accounts. Within the Spezi ecosystem, we agreed that we want to rely on JWTs as the way-to-got for decentralized authorization. Therefore, it might make sense to make providing access to the underlying JWT data structure a mandatory requirement for Account Service implementations, such that web service implementation can rely on SpeziAccount to provide access to the JWT of any kind of account.
Solution
A simple approach would be to add a new JWT-based AccountKey implementation. Refer to the Adding new Account Values guide for more information on that.
While the web service side would still need to know what JWTs it expects, the iOS-side of things could just blindly forward the respective JWT from the AccountDetails.
Additional context
No response
Code of Conduct
[X] I agree to follow this project's Code of Conduct and Contributing Guidelines
Problem
Currently, we only expect a AccountService to provide a stable
accountId
and an optional user-visibleuserId
for all accounts. Within the Spezi ecosystem, we agreed that we want to rely on JWTs as the way-to-got for decentralized authorization. Therefore, it might make sense to make providing access to the underlying JWT data structure a mandatory requirement for Account Service implementations, such that web service implementation can rely on SpeziAccount to provide access to the JWT of any kind of account.Solution
A simple approach would be to add a new
JWT
-basedAccountKey
implementation. Refer to the Adding new Account Values guide for more information on that. While the web service side would still need to know what JWTs it expects, the iOS-side of things could just blindly forward the respective JWT from theAccountDetails
.Additional context
No response
Code of Conduct