...
Jira Legacy server System Jira serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JOIDC-201 Jira Legacy server System Jira serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JCOMOIDC-113 Basic DPoP access token use case more or less covered now with token and userinfo
If public key thumbprint is stored inside our token claims sets, DPoP access tokens are issued
thumbprint may be fetched in PAR or authorize -flows, or via DPoP proof
Profile configuration option to control requirements & claims validators
TODO
nonce-management
refresh token binding (public clients)
introspection and revocation support
Jira Legacy server System Jira serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JCOMOIDC-115 Upgrade is needed for the DPoP metadata-flag support: https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/issues/467/support-for-dpop_bound_access_tokens-in
Before upgrade, we need a solution for a problem described in: https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/issues/438/non-uri-resource-indicators
...
May need to miss meeting, I have some people coming to fix our drains…
MDA 0.10.0 released. Huzzah!
Some downstream work to be done before I’m really finished.
main
is now 1.0.0-SNAPSHOT and there’s amaint-0.10
branch.I don’t see value at present in nightly and multi jobs on the maintenance branch, but will create them if needed.
New Spring Framework releases (including a new 6.2 milestone) available, will integrate those.
Next up after that: Git conversion of the Santuario repository
John
Marvin
Phil
Jira Legacy server System Jira serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JWEBAUTHN-12 Add a guard to check a user who has already registered a webauthn credential can not by to register a new webauthn credential is
Rod
Nothing
Scott
Example script to report on project status based on a CSV file
SP design and prototyping
Conceptual model is visable in https://git.shibboleth.net/view/?p=java-plugin-shibd.git;a=blob;f=sp-conf-impl/src/main/resources/net/shibboleth/idp/module/conf/sp/agents.xml;h=6f5f1171a2ca15130f8cd009a0eee2e7e678428d;hb=HEAD
Agents have a unique ID and contain Applications.
Agents will be associated with some form of identity/credential to secure requests.
Applications have an ID that is unique within a given agent and expose a RelyingPartyConfigurationResolver to resolve the correct RPC and PC for a request.
Every layer allows override of the agent’s entityID, client_id, etc. The protocol identity is thus maintained solely in shibd and is no longer a concern of the agent. The shibd deployer is the one that associates Applications with protocol settings and ensures metadata given to IdPs, if it’s needed, is correct.
Pluggable rules control the virtual hosts associated with an agent/application, similar to what supporting unregistered OIDC clients might look like.
...