-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OIDC guidance (what needs to be adhered to?) #90
Comments
This issue is another good example of implementation topics being raised in different tracks (not only CAMARA, but also GSMA and others) that are not fully defined/closed. Like issue #78 for example. It points to the need (not yet met) for an Open Gateway profile/binding documenting what are the mandatory parameters in authorisation requests for Opengateway, what are the error codes and error scenarios, what is the supported client authentication, what are the supported login hint methods for CIBA, etc. As discussed in the last WG call (29/11), CAMARA participants tend to agree that there should be an Open Gateway OIDC profile where these developer-oriented implementation details are written down in black and white. This profile is still undocumented, and it is still undecided where to place it (proposal is to place it at GSMA, considering this profile as an Opengateway profile, since CAMARA could be used outside the GSMA Opengateway context). But the information should be available for everyone to review and contribute. And your contribution to this is more than welcome. |
@ECORMAC : OIDF colleagues will be giving a presentation on 20th Dec (our next planned id-consent subproject call) to present how such conformance profiles were created in the context of FAPI. Please feel free to join the call. |
As discussed in 17/01/2024 WG meeting call, as the way forward agreed, Telefónica will contribute to CAMARA with a first draft of the OIDC profile. |
Thanks. Will the draft be published in this workgroup library? |
Yes, it will. |
Added PR with a first draft of OIDC profile. |
Problem description
In Number Verification we have adhered to the use of OIDC security scheme as per commonalities guidelines.
However OIDC as per standard would also entail the use / delivery of identity tokens. In our case (Number Verification) we don't see the need for identity tokens (but see the need for Authorization code grant).
Having checked with commonalities for some recommendation / principle that could be used to both adhere to OIDC but not use / implement identity tokens, they indicated that IdentityAndConsentManagement should be able to provide some guidance (that Number Verification and commonalities) can use.
Expected action
Clarification on the directive to adhere to OIDC - what parts are mandatory, if all parts are not mandatory is for example a compliance statement necessary in each workgroup?
Additional context
The text was updated successfully, but these errors were encountered: