Update CAMARA-ICM-examples.md with CIBA examples #237
Conversation
| @@ -92,7 +92,59 @@ login_hint=tel%3A%2B34666666666 | |||
| ``` | |||
|
|
|||
|
|
|||
| #### Successful response | |||
There was a problem hiding this comment.
I believe that the previous /bc-authorize request is missing the 'client_assertion_type' and 'client_assertion' fields.
| The Client MUST keep the auth_req_id in order to use when making a token request in Poll mode. | ||
| Expires_in and interval can differ |
There was a problem hiding this comment.
| The Client MUST keep the auth_req_id in order to use when making a token request in Poll mode. | |
| Expires_in and interval can differ | |
| The Client MUST keep the `auth_req_id` in order to use it when making a token request in Poll mode. | |
| Please note that the values for `expires_in` and `interval` may differ. |
There was a problem hiding this comment.
Why this note "Expires_in and interval can differ"? It is a strange ideas, to me, that both might be the same.
The example in CIBA means poll max for 120 seconds in a two seconds interval. What is the interpretation they are the same?
There was a problem hiding this comment.
May differ from the ones in the example. I think that's what @sebdewet meant.
There was a problem hiding this comment.
Exactly.
I can modify and specify this :
Expires_in and interval are not CAMARA Mandatory and can differ from the values above
| { | ||
| "access_token": "G5kXH2wHvUra0sHlDy1iTkDJgsgUO1bN", | ||
| "token_type": "Bearer", | ||
| "refresh_token": "4bwc0ESC_IAhflf-ACC_vjD_ltc11ne-8gFPfA2Kx16", | ||
| "expires_in": 120, | ||
| "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjE2NzcyNyJ9.eyJpc3MiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsInN1YiI6IjI0ODI4OTc2MTAwMiIsImF1ZCI6InM2QmhkUmtxdDMiLCJlbWFpbCI6Im1vY2tAZXhhbXBsZS5jb20iLCJleHAiOjE1Mzc4MTk4MDQsImlhdCI6MTUzNzgxOTUwNH0.bVq83mdy72ddIFVJLjlNBX-5JHbjmwK-Sn9Mir-blesfYMceIOw6u4GOrO_ZroDnnbJXNKWAg_dxVynvMHnk3uJc46feaRIL4zfHf6Anbf5_TbgMaVO8iczD16A5gNjSD7yenT5fslrrW-NU_vtmi0s1puoM4EmSaPXCR19vRJyWuStJiRHK5yc3BtBlQ2xwxH1iNP49rGAQe_LHfW1G74NY5DaPv-V23JXDNEIUTY-jT-NbbtNHAxnhNPyn8kcO2WOoeIwANO9BfLF1EFWtjGPPMj6kDVrikec47yK86HArGvsIIwk1uExynJIv_tgZGE0eZI7MtVb2UlCwDQrVlg" | ||
| } |
There was a problem hiding this comment.
I believe you may have overlooked the scope field. We may include an example analogous to the one in the /token response in the Auth Code Flow example for your reference.
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "eyJhbGciOiJSUz....",
"scope": "dpv:FraudPreventionAndDetection sim-swap:check sim-swap:retrieve-date"
}
There was a problem hiding this comment.
Returning scopes is then advised if the OP sends scopes that are different to what was requested. I think otherwise the API consumer can assume that the access token covers the scopes requested.
There was a problem hiding this comment.
Exactly, that’s why I didn’t specify the parameter "scope" in the example, but we can have two examples.
There was a problem hiding this comment.
Yes. scope is OPTIONAL, if identical to the scope requested by the client; otherwise, REQUIRED. It may be beneficial to include this in the example for illustrative purposes (we did in Auth Code Flow example). Then If you would like to clarify further, it could be done below the example. However, this is not a critical issue. We can proceed in the manner you prefer.
|
What is the status of this? I feel that we agree.
|
|
The CIBA |
What type of PR is this?
What this PR does / why we need it:
In CAMARA-ICM-examples.md, add CIBA examples as for Authorization code flow.
Which issue(s) this PR fixes:
Fixes #236
Special notes for reviewers:
optionnal question : In CIBA authentication request, do we define that client_assertion is mandatory ?