You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 13, 2022. It is now read-only.
currently, the webid-oidc-spec suite documents only the "user logs directly in to a server or application by selecting her OIDC OP and logging in there" case. the specifications currently don't cover the "AJAX or API client request" case where a web application accesses a restricted resource on behalf of its user, particularly on a server that isn't also the user's OP, or where an automatic agent or bot tries to access a restricted resource.
however, on inspection of the source of node-solid-server (and its dependencies solid/oidc-op, solid/oidc-rp), it appears that a solution for this case has been implemented.
this solution should be documented so the community can understand, analyze, comment on, and independently implement it.
from inspection of the source, i believe this is how it currently works:
The Solid reference implementation uses an ad hoc Proof of Possession Token (POPToken) directly as an HTTP Authorization Bearer token. Here, a POPToken is a JWT containing an OIDC id_token (which itself is independently validated and which bears a Proof of Possession key as the cnf claim), an audience binding it to the origin of the resource being accessed, and an issuer being the client to which the id_token was issued. The POPToken is signed with the private keying material associated with the cnf claim.
The text was updated successfully, but these errors were encountered:
even if the current POPToken protocol is experimental, it should still be documented.
perhaps a brief (but correct) description could be referenced by the more mature specs as "this is an open area of research. one experimental approach is ..."
Completely agree. There were some things in the background that were preventing us from updating the docs, but those all seem to be rectified now. I'll be updating everything to be in-line with the implementation and proposing it to the w3c call next week.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
currently, the webid-oidc-spec suite documents only the "user logs directly in to a server or application by selecting her OIDC OP and logging in there" case. the specifications currently don't cover the "AJAX or API client request" case where a web application accesses a restricted resource on behalf of its user, particularly on a server that isn't also the user's OP, or where an automatic agent or bot tries to access a restricted resource.
however, on inspection of the source of node-solid-server (and its dependencies solid/oidc-op, solid/oidc-rp), it appears that a solution for this case has been implemented.
this solution should be documented so the community can understand, analyze, comment on, and independently implement it.
from inspection of the source, i believe this is how it currently works:
The Solid reference implementation uses an ad hoc Proof of Possession Token (POPToken) directly as an HTTP Authorization Bearer token. Here, a POPToken is a JWT containing an OIDC
id_token
(which itself is independently validated and which bears a Proof of Possession key as thecnf
claim), anaud
ience binding it to the origin of the resource being accessed, and aniss
uer being the client to which theid_token
was issued. The POPToken is signed with the private keying material associated with thecnf
claim.The text was updated successfully, but these errors were encountered: