+1
I would also like to ensure there is a clear definition of "sender
constrained" tokens in this BCP.
Aaron
On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi all,
>
> based on your feedback on the list and off list, Daniel and I polished the
> text. T
+1 for the change.
--
-jim
Jim Willeke
On Fri, Nov 30, 2018 at 5:36 PM Dick Hardt wrote:
> + 1 to the change
>
> I'd suggest we work to define terms such as "sender constrained" in the
> BCP so that it is clear what is meant by it.
>
> On Fri, Nov 30, 2018 at 2:24 PM Brian Campbell 40pingident
On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt
wrote:
> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
> >
> > So you mean at the resource server ensuring the token was really issued
> to the client? Isn't that an inherent limitation of all bearer tokens
> (modulo HTTP token binding, which i
+ 1 to the change
I'd suggest we work to define terms such as "sender constrained" in the BCP
so that it is clear what is meant by it.
On Fri, Nov 30, 2018 at 2:24 PM Brian Campbell wrote:
> Kind of, yes. I guess so. I think. It's just semantics. But yeah. Key
> constrained might be more approp
Kind of, yes. I guess so. I think. It's just semantics. But yeah. Key
constrained might be more appropriate. But the Security Topics document
probably should allow for both/either.
I don't think that these are necessarily terms with widely agreed upon or
understood meaning. But it was pointed out
Seems correct, yes.
On Fri, Nov 30, 2018 at 1:32 PM Hannes Tschofenig
wrote:
> Hi all,
>
> Token exchange registers the 'resource' parameter, at least to a large
> extend, and draft-ietf-oauth-resource-indicators indicates this in the IANA
> consideration section.
>
> What isn't mentioned in dra
Hi Brian,
we use „sender constrained tokens“ throughout the BCP to denote tokens bound to
a sender in possession of a certain key/secret and I thought that was
established terminology in the group. Are you suggesting „key constrained”
would be more appropriate?
kind regards,
Torsten.
> Am 30.
Hi all,
Token exchange registers the 'resource' parameter, at least to a large extend,
and draft-ietf-oauth-resource-indicators indicates this in the IANA
consideration section.
What isn't mentioned in draft-ietf-oauth-resource-indicators is that token
exchange also defines the audience parame
As was pointed out to me in WGLC review of the MTLS document,
"sender-constrained" has or is likely to be interpreted with a pretty
specific meaning of the token being bound to the client and the client
authenticating itself to the resource and the resource checking all that
matches up. That makes
On Tue, Nov 20, 2018 at 12:45 PM Filip Skokan wrote:
> This is my best shot at an implementable policy when it comes to clients
> with expired client secrets: *"all operations requiring a secret will be
> rejected when an expired one is presented"*
>
This is a good list and hopefully something t
+1 from me too.
> On 29 Nov 2018, at 18:06, Torsten Lodderstedt wrote:
>
> Hi all,
>
> based on your feedback on the list and off list, Daniel and I polished the
> text. That’s our proposal:
>
> —
> In order to avoid these issues, clients MUST NOT use the implicit
> grant (response type "to
11 matches
Mail list logo
