Update yaml and sync with commonalities #60
Conversation
…ation into update-yaml-and-sync-with-commonalities
fernandopradocabrillo
requested a review
from DT-DawidWroblewski
as a code owner
|
@hdamker As commented in the issue 49 we have this |
|
@fernandopradocabrillo Probably we have to wait for camaraproject/Commonalities#57 green light before to merge this one - correct? @hdamker do you think adding x-Correlator is a blocking issue for this PR? |
|
When we state to include OpenID schema what exactly are we proposing (e.g. parts of the standard defined schema, all of it?) |
@bigludo7 Yes, also think we have to wait.
@ECORMAC the proposal is to use OIDC with a 3-legged grant flow. But no mention to further requirements like id_tokens at the moment. |
I wouldn't call it blocking, but we could carve it out here until clarified in Commonalities. I still think that it is just cluttering the OAS. |
| @@ -70,8 +70,8 @@ paths: | |||
| summary: Verifies if the received hashed/plain text phone number matches the phone number associated with the access token | |||
| description: | | |||
| Verifies if the specified phone number (either in plain text or hashed format) matches the one that the user is currently using. Only one of the plain or hashed formats must be provided. | |||
| - The number verification will be done for the user that has authenticated via mobile network and so their `sub` is in the access token | |||
| - It returns true/false depending on if the hashed phone number received as input matches the authenticated user's `device phone number` associated to the access token | |||
| - The number verification will be done for the user that has authenticated via mobile network and so their `sub` is in the access token | |||
There was a problem hiding this comment.
if we use "OpenID Connect" sub is one of id_token claims.
@fernandopradocabrillo please review
There was a problem hiding this comment.
afaik access_tokens also contains the sub: https://auth0.com/docs/authenticate/login/oidc-conformant-authentication/oidc-adoption-access-tokens#standard-claims
There was a problem hiding this comment.
it depends...
following RFC:
Access tokens can have different formats, structures, and methods of
utilization (e.g., cryptographic properties) based on the resource
server security requirements. Access token attributes and the
methods used to access protected resources are beyond the scope of
this specification and are defined by companion specifications such
as RFC6750.
and sub required claim inside ID Token, that is something specific for OpenId Connect, as it is designed for authentication (& authorization).
ID Token
So you can state that:
sub is build in OpenID Connect, as it is a part of id_token, and is optional for OAUTH2.0 as it depends on resource server security requirements.
Therefore, if we're willing to use access_tokens we should use OAUTH2.0 security scheme.
| /device-phone-number: | ||
| get: | ||
| tags: | ||
| - Phone number share | ||
| summary: Returns the phone number associated with the access token | ||
| description: | | ||
| Returns the phone number so the API clients can verify the number themselves: | ||
| - It will be done for the user that has authenticated via mobile network and so their `sub` is in the access token | ||
| - It returns the authenticated user's `device phone number` associated to the access token | ||
| - It will be done for the user that has authenticated via mobile network and so their `sub` is in the access token |
|
Agree with David, "sub" is defined in relation to identity tokens (can't find it being mentioned in any spec in relation to access tokens). The current description in the Yaml is confusing, it should be clarified what we are proposing. |
|
@DT-DawidWroblewski |
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes (#49) Defines CAMARA scope for the CAMARA version
Special notes for reviewers:
N/A
Changelog input
N/A
Additional documentation
N/A