Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Clarify verifiable claims TLS requirement. #16

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Clarify verifiable claims TLS requirement. #16

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -455,6 +455,8 @@ specification.

All tokens, Client, and User credentials MUST only be transmitted over TLS.

All resources required to verify claims: Issuer, WebID and Client WebID; MUST only be transmitted over TLS.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the intention here is good, but I'm concerned that this might be over-specifying things.

First, an RS may cache JWKS resources in a local keystore (hence, transfer is between local keystore and application, which may not be TLS)
Second, there may be other secure transfer mechanisms (mTLS) that are possible
Third, WebID documents (according to the WebID spec) may use either the http or https scheme
Fourth, if a WebID is a DID, the resolver may have its own mechanism to securely transfer resources

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Part of my concern is specifically about WebIDs being transferred over an insecure connection.

I imagine it is not an obvious security concern since the trusted issuer check is "always?" going to be a backchannel operation.

But I'm not a security expert and it would be good to have a serious opinion on that and understand the implications.

No matter what, I would tend to think (even though it's beyond my capacity to exploit it) that having an insecure connection involved in authentication is a serious attack vector.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is principally about WebID documents using http vs https schemes, then the text in this PR should focus on how this specification constrains how the WebID specification should be followed.


## Client IDs ## {#security-client-ids}

An RS SHOULD assign a fixed set of low trust policies to any client identified as anonymous.
Expand Down