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
I have a lot to say about this section, but let's start with the big one:
Token challenges can be performed without explicit user involvement, depending on the issuance protocol.
That's at best misleading. There are multiple factors that might cause a client to supply a token without user involvement, but the choice of protocol is not something that is relevant. Sure, there might be cases where something makes user involvement necessary, but this is not the overriding concern.
The main concern is that the token carries information from one context to another and the Web generally tries to avoid that happening without very good reason. In order to overcome that, most clients/user agents will want to ensure that a number of conditions are met.
We don't need to go into those conditions here, because this is an IETF specification. In fact, most of this section doesn't belong in an IETF specification as it relates to decisions that web user agents might choose to make. In other contexts, the considerations are different and so different constraints might be appropriate.
I'll go further and say that while this specification is clearly designed for the Web, it is not fit for that purpose.
What this document needs is a section explaining how a client might choose to use tokens, what the risks involved are, and how those risks might be mitigated. Some of that is probably already in the architecture document, but this document makes a lot of that quite concrete. A brief overview of the challenges that is backed by references to the architecture is probably worthwhile.
The text was updated successfully, but these errors were encountered:
I have a lot to say about this section, but let's start with the big one:
That's at best misleading. There are multiple factors that might cause a client to supply a token without user involvement, but the choice of protocol is not something that is relevant. Sure, there might be cases where something makes user involvement necessary, but this is not the overriding concern.
The main concern is that the token carries information from one context to another and the Web generally tries to avoid that happening without very good reason. In order to overcome that, most clients/user agents will want to ensure that a number of conditions are met.
We don't need to go into those conditions here, because this is an IETF specification. In fact, most of this section doesn't belong in an IETF specification as it relates to decisions that web user agents might choose to make. In other contexts, the considerations are different and so different constraints might be appropriate.
I'll go further and say that while this specification is clearly designed for the Web, it is not fit for that purpose.
What this document needs is a section explaining how a client might choose to use tokens, what the risks involved are, and how those risks might be mitigated. Some of that is probably already in the architecture document, but this document makes a lot of that quite concrete. A brief overview of the challenges that is backed by references to the architecture is probably worthwhile.
The text was updated successfully, but these errors were encountered: