Hi,
Glad to see DPoP moving forward as a working group item.
I have a couple of comments on the current draft:
1.
I recommend expanding the description of the threat model.
It's not entirely clear to me what threats DPoP is expected to address, which
makes it hard to evaluate whether DPoP meets
This looks like a great initial draft, and I hope to see it move forward.
Some comments so far:
Section 1.6:
“At the time of this writing” is duplicated.
Section 3.1.2.1 (and possibly other sections such as 1.6 / 2.3.1 / 3.1 / 3.2
that mandate TLS):
Section 3.1.2.1 currently retains this
r. First one says "RECOMMENDED lifetimes", second one says "MUST have
a valid lifetime no greater than one hour".
- I was surprised that the Security BCP does not show up in Section 6.
-Daniel
[1] https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md
Am 02
Hello all,
For anyone who may be interested: MITRE, in support of the U.S. Government, has
developed tailored OAuth and OpenID Connect profiles for use in enterprise
environments. We have leveraged previous standards efforts (e.g. work in the
IETF and in the OpenID Foundation) and have
Thank you for writing this BCP. I believe it provides important guidance and
support its publication.
I have the following comments on draft -13:
Overall:
The draft uses the term “adversary” (3 times) and the term “attacker” (>100
times). I suggest using one term consistently.
My
Hi Pedram,
I understand why a client would need to allow use of multiple authorization
servers if the client needs to access various resource servers each of which
may trust different ASs (e.g. the client supports accessing resources at
multiple cloud storage services).
However, how common is
To explain my comment at the microphone today:
Section 8 states:
JWTs use JSON Web Signature (JWS)
[JWShttp://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#ref-JWS]
and JSON Web Encryption (JWE)
[JWEhttp://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#ref-JWE] to
sign