sef wrote:
>
> Hi Spencer
>
> Sure. When are yo planning on submitting the draft?
>
> Regards,
> Rifaat
>
>
> On Mon, Oct 14, 2019 at 5:20 AM Travis Spencer
> wrote:
>>
>> I would like a slot to talk about a new draft I'm going to submit in the
On Wed, Oct 23, 2019 at 2:11 PM Brian Campbell
wrote:
> I agree with Ben here that it's not at all clear that the OAuth MTLS document
> should have defined a protocol from proxy to backend.
Shouldn't it at least normalitvely reference some other spec then? If
that reference is not defined before
Submitted: https://datatracker.ietf.org/doc/draft-spencer-oauth-claims/
On Fri, Nov 1, 2019 at 5:57 PM Rifaat Shekh-Yusef wrote:
>
> Sounds good.
>
> On Fri, Nov 1, 2019 at 12:56 PM Travis Spencer
> wrote:
>>
>> I see that the deadline is Monday.[1] I'll work th
On Tue, Dec 24, 2019 at 12:27 AM Brian Campbell
wrote:
>
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.3.2
> has "Replace implicit flow with postmessage communication or ..." but without
> a defined and interoperable way of using postmessage communication in place
On Fri, Feb 19, 2021 at 10:09 PM Brian Campbell
wrote:
> Publishing an independent stream RFC that runs contrary to the BCP
> coming out of the WG does seem potentially harmful.
>
> On Mon, Feb 15, 2021 at 11:59 AM RFC ISE (Adrian Farrel)
> wrote:
>> I want to be sure that ... there is no percei
mo as well; just grab us.
We're eager to receive feedback on this new proposal, and hope to
discuss more in London.
--
Regards,
Travis Spencer
[1] https://zisc.ethz.ch/oauth-security-workshop-2017/
[2] https://zisc.ethz.ch/wp-content/uploads/2017/02/ideskog_assisted-token.pdf
[3] htt
I read through this doc and would like to share a bit of feedback in
hopes that it helps:
* There is no mention of Content Security Policy (CSP). This is a very
helpful security mechanism that all OAuth servers and web-based
clients should implement. I think this needs to be addressed in this
doc.
On Wed, Mar 21, 2018 at 8:36 AM, Brian Campbell
wrote:
> Doing redirection in error conditions relates to OpenID Connect flows too.
Also Mobile Connect. Those folks will be very upset by this change, I'm sure.
___
OAuth mailing list
OAuth@ietf.org
http
On Wed, Mar 21, 2018 at 8:34 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> The AS MUST take precautions to prevent this threat.
> Based on its risk assessment the AS needs to decide whether
> it can trust the redirect URI or not and should only automatically
> redirect the user agent
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
No. The initial access token is issued by the AS when registration is
protected (appendix 1.2 in RFC 7591). As stated in section 1.2, the method
and means by which this is obtained can vary. The registration access token
in RFC 7592 is used to protect the registration management API and allow
updat
ent_id] through
> RFC7591 initial registration, it is then able to ask for an access token
> that will be used for accessing the RFC7592 entry-points. Am I right?
>
>
>
> Best regards
>
>
>
> Hervé
>
>
>
> *De :* Travis Spencer [mailto:travis.spen...@curity.
On Fri, Sep 13, 2019 at 3:18 PM Travis Spencer
wrote:
> Ya, this part is confusing. I didn't get it at first either.
>
Seems I'm still a bit confused ;-)
this metadata isn't defined in RFC 7591 but discussed in section 1.3; that
> spec leaves the metadata out of scope.
Some feedback on this draft compared to the last one that I read:
* The acronym RS and the term "resource server" are used
inconsistently. It would read better IMO if the acronym was always
used after being defined or if resource server was always spelled out.
Same for AS, but less so. Maybe this
On Sat, Sep 28, 2019 at 12:51 AM Benjamin Kaduk wrote:
> On Thu, Sep 26, 2019 at 11:26:31AM +0200, Travis Spencer wrote:
> > * Last but certainly not least is the restriction that the current
> > version places on disallowing of the introspection JWT response as an
> > acces
I would like a slot to talk about a new draft I'm going to submit in the
coming weeks related to claims (i.e., structured scopes). Would that be
possible?
On Fri, Oct 4, 2019 at 11:15 PM Dick Hardt wrote:
> I'd like a slot to provide an update on Reciprocal OAuth.
> ᐧ
>
> On Fri, Oct 4, 2019 at
On Wed, Sep 18, 2019 at 4:24 PM Dick Hardt wrote:
>
> What happens if the access token is lost or compromised? Does the app need to
> be completely re-registered?
Yes. Re-registration breaks many things though, so it's often not an
option. In these cases, the client is pretty much stuck with onl
On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt
wrote:
> Hi Travis,
Hey there, Torsten. Sorry for the slow reply. Still jet lagged ;-)
> > On 26. Sep 2019, at 11:26, Travis Spencer wrote:
> Do others have an opinion about this?
https://tools.ietf.org/html/rfc7322#section-3.6
&
18 matches
Mail list logo
