On Wed, Apr 14, 2021 at 1:19 AM Vittorio Bertocci wrote:
> > 3. -
> > [...]
>
> Formally, I agree that JOSE would also work. The choice of media type
> derives from https://tools.ietf.org/html/rfc7519#section-10.3.1. There is
> no functional difference between JWS and JWE in the intent a
Hi Vittorio,
Since Murray raised the concern, I have responded. A *guidance *section
should not contain any *MUST*, *SHALL*, *MUST *or *SHALL NOT.*
I believe that my proposal is a fair compromise on this topic by keeping
all the sentences, except the first half of the second paragraph
of
Hi Denis, this aspect was debated at length (one example in
https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/, there
are many others) and the consensus reflected in the current text was clear.
From: Denis
Sent: Wednesday, April 14, 2021 1:19 AM
To: Vittorio Bertocci
All,
This is to start a WG Last Call on the *Security BCP *document, that
ends *April
28.*
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
Please, review the document and raise any *new* concerns you have with this
document.
Regards,
Rifaat & Hannes
Hi Murray,
Thank you for your comments. I come back on one of your comments (while
other comments and Vittorio's responses are deleted):
The first half of the second paragraph of Section 6 seems much more
like an interoperability issue than a privacy issue to me.
I agree that, taken in
Hi Rifaat,
One addition that may be useful:
Before the sentence: "Hannes: I was not aware of this work in ISO",
there is a sentence missing:
Denis: ISO/SC 27/WG 5 is just starting to work on PWI about age
verification. If you are a member of ISO / SC 27/ WG 5 you can
contribute.
Thanks Martin for the comments and Benjamin for addressing some of them!
Comments on the remaining ones:
> (2.1) "...can use any signing algorithm." I presume there ought to be some
> qualifiers on allowed algorithms?
The algorithms referred to here are the ones defined by the usual
Hi Francesca,
Thanks for your review and thoughtful comments!
Comments below.
>1. -
>[...]
While it is reasonable to expect that a RS receiving an unencrypted token after
requesting it to be encrypted will reject it, there are a number of cases where
the RS might elect to do
Hi Murray,
Thank you for your comments! Answers inline
> My co-AD pretty much nailed it. I would go further and say that her
> comment
>about "Why is this only SHOULD?" applies to a lot of the SHOULDs in here.
>SHOULD presents a choice; why might an implementer reasonably not do any
Hi Roberto,
Thanks for the comments and apologies for the delay. Inline
* An example with client_credential grant type would be nice too.
Are you thinking of specific aspects that aren’t sufficiently clear from the
text that would be clarified by one example? Unless there’s something
10 matches
Mail list logo