-
Notifications
You must be signed in to change notification settings - Fork 25
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
request_uri extension #59
Changes from 1 commit
0ef69f7
b402aa7
673fcf7
9dff282
f945d54
0a42d0f
37fbccf
b7c2570
350391d
7822756
8056fc1
9061d50
ba585be
b1ee70e
d29107b
d198019
30d59a8
63a86f7
70ac39b
e35ab32
8cb645f
0ced90a
42f6866
4f335fc
18fd478
bfc2bdc
acd0c13
1101fda
c1ee35a
357222c
0844acb
f0fa298
cfb2d36
2c49b9b
21696fd
a8f4917
2f08615
9a021bb
8719239
e7b8871
9d78904
0e58e39
af6c572
02a58d0
76098d7
8666529
396f007
b1e94aa
d9a49d9
63d1f7f
6edd8d1
e8a6cde
e1276ec
6d5601b
c4d175b
3b0a9fb
df5d0f1
f4e4236
ac1ffc0
803cbe6
95ac037
6890440
148e1bd
ae65453
e3df8ac
0c9413d
91f811f
56ef646
a21eba3
efd0722
4ea299d
3208b16
55a4faf
5a0b1af
bee5ed9
286bf67
3c298b7
4540cca
e5add86
06aef10
e437b50
4140e35
1e033f7
d167829
fb39140
674d0aa
fe8ae63
1088682
c6057d9
e937d3a
f36cfe6
cdfea43
1737a30
d2ba099
a478244
c6db7d5
d3e6894
17a60fc
ada0a45
6f9c661
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -19,9 +19,9 @@ end box | |||||
u --> r : use | ||||||
activate r | ||||||
|
||||||
r --> u: **signed authorization request**\n(client_id, request_uri, request_uri_mode=POST, state) | ||||||
r --> u: authorization request\n(client_id, request{request_uri, request_uri_mode=POST, state}) | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is the intention of reusing the request_uri here? It will not work because according to this PR the request_uri is not a URI but a Request Object? Request_uri has to remain the same according to RFC9101 to have backwards-compatiblity. If this intending to be a breaking change then we should not overload request_uri but make the different paths more clear There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. similar comment as above, right? See my answer there, pls. |
||||||
deactivate r | ||||||
u --> w: **signed authorization request**\n(client_id, request_uri, request_uri_mode=POST, state) | ||||||
u --> w: authorization request\n(client_id, request{request_uri, request_uri_mode=POST, state}) | ||||||
activate w | ||||||
w --> w: check authorization request signature | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess we need to add this in the spec text? Please add the respective comment(s) where you would like to see it added. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems quite normative to me and this comment/request4change should be moved in the normative text and not in this sequence diagram example do you agree @awoie ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. added requested normative text There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
IMO, it is important that the |
||||||
w --> w: check on trustworthiness of Verifier (approach on trust mechanism) | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. reliability is not the right association with trust evaluation imo There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think trust (or trustworthiness) is the right term. If there is no trust, the Wallet should not send a request to the Verifier's request URI. |
||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't the state parameter provided in the request object obtained from the request_uri?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's contained in both, where the state from the authorization request is sent to the request URI. This allows the verifier to identify the origin/context of the request URI request. It then may add a state to the new request object, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, points below needs clarifications: