> Am 27.11.2018 um 21:54 schrieb William Denniss :
>
> +1 to have language recommending against the use in most cases (without
> needing to exclude Nat's use-case).
Can you (or someone else) propose text?
smime.p7s
Description: S/MIME cryptographic signature
___
to do with the SPA use case.
>
> John B.
>
>> On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote:
>> Hi John,
>>
>> as you said, self issued IDPs
>> (https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) are
>> supposed to provide the respo
section still has two uses of "SHALL“.
Fixed it.
>
> Thanks! Overall I'm happy to see this guidance!
Thanks.
kind regards,
Torsten.
>
>
> Aaron Parecki
> aaronparecki.com
>
>
>
> On Tue, Nov 20, 2018 at 11:33 AM Torsten Lodderstedt
> wrote:
&
the grant associated with the refresh token (and its sensitivity).
Proposals are welcome!
kind regards,
Torsten.
>
> This is in addition to the other best practices described.
>
> Thanks,
> George
>
> On 11/20/18 2:32 PM, Torsten Lodderstedt wrote:
>> Hi all,
>
My understanding is that cookies are not blocked on redirects (IPT2/Safari)
> but I haven't done extensive testing. So from a full-page redirect
> perspective there should be no issues, from a hidden iframe I'm not sure...
> but I believe it will work.
>
>
> On 11/21/
> Am 28.11.2018 um 16:53 schrieb George Fletcher :
>
> On 11/28/18 5:11 AM, Torsten Lodderstedt wrote:
>> Hi George,
>>
>>> Am 20.11.2018 um 23:38 schrieb George Fletcher :
>>>
>>> Thanks for the additional section on refresh_tokens. Some a
Hi Nat,
> Am 28.11.2018 um 21:10 schrieb n-sakimura :
>
> I would support
>
> 1) clearly defining Implicit as the flow that returns access token from the
> authorization endpoint ( some people confuses implicit as the flow that
> returns ID Token in the front channel)
That’s the current text
ded for the named recipient
> only.
> If you are not an intended recipient, please notify the sender and delete
> this e-mail.
>
> 差出人: Torsten Lodderstedt
> 送信日時: 水曜日, 11月 28, 2018 11:38 午後
> 宛先: n-sakimura
> Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> 件名: Re
chrieb John Bradley :
>
> I am ok with that.
>
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt wrote:
>
> > Am 28.11.2018 um 23:50 schrieb n-sakimura :
> >
> > That works.
>
> Good!
>
> I just realized this text has an issue with „toke
ed and a
>> concrete/actionable list of the affected response types.
>> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported
>> by William
>>
>> We look forward to seeing your feedback.
>>
>> kind regards,
>> Torsten.
>>
s (which does not work today but might work in the future).
kind regards,
Torsten.
>
> Am I misunderstanding it?
>
> Ciao
> Hannes
>
> PS: The IoT case is likely different.
>
> From: OAuth On Behalf Of Aaron Parecki
> Sent: Saturday, December 1, 2018
Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig :
>
> I share the concern Brian has, which is also the conclusion I came up with in
> my other email sent a few minutes ago.
>
> From: OAuth On Behalf Of Brian Campbell
> Sent: Friday, November 30, 2018 11:43 PM
> To: Torsten
techniques (see
OWASP). The backend in turn can use mTLS for sender constraining.
> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt :
>
> IMHO the best mechanism at hand currently to cope with token leakage/replay
> in SPAs is to use refresh tokens (rotating w/ replay detection) and is
the need to fully expose them.
> Am 02.12.2018 um 00:44 schrieb John Bradley :
>
> How is that different from a regular server client with a web interface if
> the backed is doing the API calls to the RS?
>
>
>
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>
to the
> backend, to associate it with the correct token(s)?
>
> Cheers (and really interesting discussion so far)
>
> Rob
>
>> On Sun, 2 Dec 2018 at 07:31, Torsten Lodderstedt
>> wrote:
>> the UI is rendered in the frontend, UI control flow is in th
t;
>>> I wouldn't have expected an Angular app that talks to its own server
>>> backend that's managing OAuth credentials to fall under the umbrella of
>>> this BCP.
>>>
>>>
>>> Aaron Parecki
>>> aaronparecki.com
---
> Aaron Parecki
> aaronparecki.com
>
>
>
> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt
> wrote:
> the UI is rendered in the frontend, UI control flow is in the frontend. just
> a different cut through the web app’s layering
>
> All Angular apps I h
throw away all the stash they have of the
>> older drug. The old drug will keep working as it worked until now. Once they
>> run out of their stash, they should get the new one; or if the old side
>> effects were particularly bad for them, perhaps they should consider
>&
Hi Tomek,
> Am 04.12.2018 um 09:50 schrieb Tomek Stojecki
> :
>
> I agree with Vittorio, Dominick et al.
>
>> I disagree.
>
>> Existing deployments that have not mitigated against the concerns with
>> implicit should be ripped up and updated.
>
> Yes, just like future deployments that will
h token rotation if you would use public key crypto for
client authentication.
> confidentiality in storage? - not sure how to read that in the context of a
> browser)
How do you ensure confidentiality of session cookies?
kind regards,
Torsten.
>
> On Tuesday, December 4, 2018, 2:08:55 PM GMT+
Hi Tomek,
> Am 05.12.2018 um 15:27 schrieb Tomek Stojecki :
>
> Hi Torsten,
>
> On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt
> wrote:
>
>
> >> So if I am putting myself in the shoes of somebody who sets out to do that
> &g
retrieve a code in the same
> way in which we used fragments to get new ATs?
That’s what I meant. I also think the RT-based approach is better suited in
terms of UX and security.
> Thx
> V.
>
>> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt
>> wrote:
&
This typically
requires frontend interactions and OpenID Connect (session mgmt or logout).
In the API case, the AS can just revoke the RT when the logout happens.
kind regards,
Torsten.
>
> Thx
> V.
>
> On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt
> wrote:
>
>
accordingly, or we manage the persistence of the RT at the application side.
You mean discard the RT or revoke it explicitly on the app side?
> The latter seems much easier to achieve to me, and above all more immediately
> actionable given that I doubt providers will be very prompt in introduci
Hi Nov,
> Am 08.12.2018 um 00:20 schrieb Nov Matake :
>
> For me, it seems very hard to issue TB-bound token for JS app and MTLS-bound
> token for its backend server at same time.
Issuing TB tokens in case of implicit is anyway hard. You need to issue a HTTP
redirect to the RS and the RS must
> Am 08.12.2018 um 16:55 schrieb Nov Matake :
>
> But even using code flow, issuing TB-bound access token has same difficulty,
> doesn't it?
> I don’t think this issue is relate to implicit flow.
Determining the referred token binding id and proving ownership of the key
isn’t easy. Brian is t
Hi Hannes,
while I think the current text needs some substantial work, I support the
adoption of this draft as a working group document. I also think we need to
carefully define the boundaries between the Security BCP and the SPA BCP in
order to prevent unnecessary duplications and inconsisten
OAuth 2.0 Security Best Current Practice
> Authors : Torsten Lodderstedt
> John Bradley
> Andrey Labunets
> Daniel Fett
> Filename: draft-ietf-oauth-security-topics-11.txt
&g
Hi all,
the Call for Proposal for the 4th OAuth Security Workshop is out!
https://sec.uni-stuttgart.de/events/osw2019
Please propose a session!
kind regards,
Torsten.
smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth
Hi Phil,
> Am 16.01.2019 um 00:38 schrieb Phil Hunt :
>
> I have had a couple reviewers comment whether this means client
> authentication is optional in Sec 3.12 for token refresh:
>
>>* authentication of this client_id during token refresh, if
>> possible, and
This just cites RFC
+1 for defining an optional mtls endpoints section
I first leaned towards a second metadata file, mainly due to the potential
token endpoint authentication method issue. But adding a secondary metadata
configuration just for this purpose seems a bit over engineered and would take
a lot of norma
Hi all,
I just published an article about the subject at:
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
I look forward to getting your feedback.
kind regards,
Torsten.
___
OAuth mailing
de.
> In our case we may also have a requirement to encrypt the pushed request
> object due to potential sensitive content.
TLS is not enough?
kind regards,
Torsten.
>
> - Steinar
>
>
> lør. 20. apr. 2019 kl. 20:21 skrev Torsten Lodderstedt
> :
> Hi all,
>
> I
a document with this idea in mind and I'm happy to
> share it with you and see what you think.
>
Look forward to reading your article.
best regards,
Torsten.
> Best regards.
> Pedro Igor
>
> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt
> wrote:
> Hi all
hich brings us back to the
original question of my article.
best regards.
Torsten.
>
>
> >
> > I've started to write a document with this idea in mind and I'm happy to
> > share it with you and see what you think.
> >
>
> Look forward to
o know the constraints imposed
>> by the RS to their protected resources (e.g. scopes).
>>
>> I've started to write a document with this idea in mind and I'm happy to
>> share it with you and see what you think.
>>
>> Best regards.
>>
gt; I'm talking about is not based on user consent.
>>>
>>> Right, you mentioned it is intended to be used for 1st parties only.
>>>
>>> > But considering that you can also pass any information to the AS, you
>>> > should be able to let users t
this capability exists :)
>
>> On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:
>> The problem from my perspective (and my understanding of UMA) is the RS does
>> not have any information about the context of the request. For example, the
>> client might be calling a certa
equired identifier
> within the 'structures_scope' document that identifies the profile it
> should be used for.
What does profile mean in this context?
best regards,
Torsten.
>
> Thank you,
> Sascha
>
> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
> :
&g
value into a URI with query string parameters, e.g.
>
> https://scopes.myapp.com/sign?credentialID=qes_eidas&documentDigests.hash=sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI&documentDigests.label=Mobile%20Subscription%20Contract&hashAlgorithmOID=2.16.840.1.101.3.4.2.1
>
>>
Apr 2019, at 17:14, Sascha Preibisch wrote:
>
> Hi Torsten!
>
> If 'structured_scope' would become a generic field for application
> specific content, I believe an indicator for the type of content would
> be needed on the long run. That is what I meant my 'pro
ific, correct?
API (e.g. all psd2 standards), ecosystem, single deployment - just like
„traditional“ scope values
>
>> On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:
>> Hi Sascha,
>>
>> I see. I assume every element within the structured scope element to be an
>>
> Am 28.04.2019 um 06:08 schrieb Benjamin Kaduk :
>
>> On Wed, Apr 24, 2019 at 07:08:25PM +0200, Torsten Lodderstedt wrote:
>> Hi Sascha,
>>
>> I see. I assume every element within the structured scope element to be an
>> independent scope (value) object
be able to propose additionally, I would suggest renaming
> "structured_scope" to a more generic name.
>
> Best Regards,
> Takahiko Kawasaki
> Representative director, Authlete, Inc.
>
> 2019年4月21日(日) 3:21 Torsten Lodderstedt :
>> Hi all,
>>
>> I
; "amount": "123.50"
> },
> "debtorAccount": {
> "iban": "DE40100100103307118608"
> },
> "creditorName": "Merchant123",
> "creditorAccount": {
> "iban": "DE02100100109307118603"
> Am 26.04.2019 um 16:17 schrieb George Fletcher :
>
>
>
>> On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
>>
>>
>> Am 25.04.2019 um 17:03 schrieb George Fletcher :
>>
>>> A couple of thoughts...
>>>
>>> 1. It doesn&#
e
> server is going to need to pull the same transactional requirements when it
> receives the access token.
All in one place :-)
best,
Torsten.
>
> Thanks,
> George
>
> On 4/26/19 10:17 AM, George Fletcher wrote:
>>
>>
>> On 4/25/19 1:54 PM, Torst
ly of one another. So I'd argue that they
> should be developed independently too.
I agree. I’m considering two separate drafts.
>
>
>
> On Sat, Apr 20, 2019 at 12:21 PM Torsten Lodderstedt
> wrote:
> Hi all,
>
> I just published an article about the subject at:
s are not only relevant for authorisation of
> transactions, but also for any access that needs authorisation.
I agree again :-) A structured scope draft should definitely not limit the
mechanism to transaction authorization.
>
> I’m not sure if i express myself clearly, nevertheless an
Hi Phil,
since mTLS is used at the tokens endpoint, native apps can definitely use their
own key pair. I would asunder such an app to act as public client, but mTLS
would allow such an app to bind its key pair with the token request to the
issued tokens.
Apps running in the browser is a separ
Hi Ben,
understood! It seems some scheme identifier would be helpful.
thanks,
Torsten.
> Am 03.05.2019 um 03:12 schrieb Benjamin Kaduk :
>
>> On Tue, Apr 30, 2019 at 12:08:32PM +0200, Torsten Lodderstedt wrote:
>>
>>
>>>> Am 28.04.2019 um 06:08 schrieb Ben
aier
>>>>> wrote:
>>>>>
>>>>> Yes I know - and I think in hindsight it was a mistake to use the same
>>>>> claim type for multiple semantics.
>>>>>
>>>>>
>>>>>
>>>>> All the
Hi,
mTLS is dead simple to use, secure, is used and can be used on a broad basis
(in contrast to the token binding stuff). I also like the fact it provides both
client authentication and sender-constraining.
We started the work on DPoP for the simple reason that SPAs don’t work well
with mTLS
ed. This is very valuable for SaaS providers.
> We expect to eventually deploy a DPoP like solution for all client models and
> not just SPA.
>
> -Karl
>
>> On May 7, 2019, at 10:43 AM, Torsten Lodderstedt
>> wrote:
>>
>> Hi,
>>
>>
aneek/using-mutual-tls-authentication-in-a-serverless-world-3afd19a6fe70
As far as I understand this article, it’s mainly about PKI. So again, use mTLS
in conjunction with self-signed certs and optional_no_ca.
kind regards,
Torsten.
>
> -Karl
>
>> On May 7, 2019, at 11:17 AM, To
>>> Thanks
>>>>>
>>>>> V.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <
>>>>> hans.zandb...@zmartzone.eu <m
You are right. May I ask you to propose text (threat description, advice, ...)
to be included in the BCP?
> On 7. May 2019, at 13:23, Neil Madden wrote:
>
> The same issue applies to token introspection responses though.
>
>> On 7 May 2019, at 12:21, Torsten Lodderstedt
> Am 10.05.2019 um 22:27 schrieb George Fletcher :
>
> One thing to keep in mind with the "Push Request Object" model and the
> concept of a more detailed scope structure, if the specified values are not
> for a single transaction, then the AS will be required to keep the "Pushed
> Request Ob
Rifaat,
I’m not aware of any IPR regarding
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/.
kind regards,
Torsten.
> Am 31.05.2019 um 14:25 schrieb Rifaat Shekh-Yusef :
>
> Torsten and Vladimir,
>
> As part of the shepherd write-up for the JWT Response for OAuth
a work item of the Web Authorization Protocol WG of the IETF.
>
>Title : JWT Response for OAuth Token Introspection
> Authors : Torsten Lodderstedt
> Vladimir Dzhuvinov
> Filename: draft-ietf-oauth-jwt-intro
Hi Roman,
thanks a lot for your review feedback.
I just published a new revision of the draft incorporating changes based on
your comments.
https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-04
> On 17. Jul 2019, at 18:17, Roman Danyliw wrote:
>
> Hi!
>
> The followi
Hi Neil,
> On 22. Jul 2019, at 13:59, Neil Madden wrote:
>
>> In addition, a public client which does not use its refresh token in an
>> “offline” manner may have theft go unnoticed for a considerable period of
>> time, and the operational model of public clients usually puts detection of
>>
Hi David,
> On 12. Jun 2019, at 04:01, David Waite wrote:
>
> To prevent exfiltration, the options are limited.
> - Token Binding will work, but only currently has support in Edge.
> - Mutual TLS will work, but has a poor experience unless you are deploying
> alongside group policy.
> - DPoP
Hi James,
> On 11. Jun 2019, at 17:53, James Howe wrote:
>
> Unless I'm mistaken, RFC 7009 doesn't specify the error response when the
> request is from a different client to the issuer.
>
> Section 2.1:
>> If this validation fails, the request is refused and the client is informed
>> of the
Hi Aaron,
thanks for your continued work on the topic.
Here are some general remarks on the current revision:
1) This BCP should not be limited to public clients. Your BCP itself already
describes an architecture where the OAuth client is a backend that may be a
confidential client (see sec
Hi Vittorio,
thanks for contributing this specification. It fills a further gap in the OAuth
universe :-)
Here are my comments:
- 2.2.1 there are other sources for identity claims, e.g.
https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html.
I recommend to open the clause
"An
OIDC RPs in the wild that do
generally not honor the type (as long as we do not update OIDC Core to require
this and it is being adopted). I think since your draft requires both, iss and
aud to be present, this threat is being dealt with. Additionally stating that
unique audiences shall be used
anks!
> V.
>
>> On Mon, Jul 22, 2019 at 9:25 AM Torsten Lodderstedt
>> wrote:
>>
>>
>> > On 22. Jul 2019, at 17:13, Vittorio Bertocci
>> > wrote:
>> >
>> > Thank you Torsten for the prompt review and insightful comments!
>
of
> draft-ietf-oauth-jwt-bcp-04
>
> == Outdated reference: A later version (-13) exists of
> draft-ietf-oauth-security-topics-11
>
> ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346)
> ==[ snip ]==
>
> Roman
>
>> -Original Message--
> Am 24.07.2019 um 00:02 schrieb Roman Danyliw :
>
> With the IETF LC feedback can you please address this idnit introduced in
> this update:
sure
smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://ww
Am 24.07.2019 um 22:13 schrieb Aaron Parecki :
>> 2) Regarding architectures: I think this BCP should focus on recommendations
>> for securely implementing OAuth in the different potential architecture. I
>> don’t think we should get into the business of recommending and assessing
>> other so
> Am 24.07.2019 um 04:13 schrieb David Waite :
>
> Perhaps it should be turned into a stated document assumption (that the
> reader has decided to use OAuth) rather than guidance later in the document
> (that OAuth may not be the best fit)
+1
smime.p7s
Description: S/MIME cryptographic signa
t;
> Thanks,
> Tomek
>
>
> On Wednesday, July 24, 2019, 04:14:14 AM GMT+2, David Waite
> wrote:
>
>
>
>
>
>
>
>> On Jul 23, 2019, at 12:47 PM, Brian Campbell
>> wrote:
>>
>>
>>
>>> On Mon, Jul 22, 2019 at 7:31 AM Torst
Hi Remco,
> On 6. Aug 2019, at 16:01, Schaar, R.M. (Remco) - Logius
> wrote:
>
> Hello,
>
> I would like to request the OAuth2 working group on a clarification for
> introspection, in particular regarding the semantics of the ‘jti’ and ‘aud’
> claims. The draft ‘JWT Response for OAuth Token
Hi Filip,
In my understanding, duplication of request parameters outside of the request
object was necessary in the OIDC variant in order to retain OAuth compliance.
JAR as an OAuth extension will not require the client to duplicate OAuth
request parameters outside of the request object.
The
of applicable parameters, to reduce the size of access tokens. Additional
> information can be exchanged via introspection, resulting in mixed JWT access
> tokens and introspection as well.
That’s all possible within the current text.
kind regards,
Torsten
>
> Kind regards,
> Re
> Am 28.08.2019 um 23:23 schrieb Filip Skokan :
>
> - allows merging request object and regular parameters with request object
> taking precedence since it is a very useful feature when having pre-signed
> request object that's not one time use and clients using it wish to vary
> state/nonce
Hi Alexey,
> On 28. Aug 2019, at 13:21, Alexey Melnikov via Datatracker
> wrote:
>
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-oauth-jwt-introspection-response-06: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addres
do
>> differ and matter.
>
> As I described above, I don’t see any difference.
>
>>
>> Another use case would be a mixed ecosystem with resource servers relying on
>> introspection while others do parse JWT access tokens. A single, uniform
>> implementatio
Hi Ben,
thanks a lot for your review comments.
We just published a new revision that is intended to resolve all your DISCUSS
and COMMENT.
https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08
> On 3. Sep 2019, at 00:44, Benjamin Kaduk via Datatracker
> wrote:
>
> Ben
Hi Alissa,
Thanks for your review.
We decided to remove the registration requests for OpenID Connect claims from
the draft in the latest revision.
https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08
Those claims are already registered in the JWT Claims registry, which
Hi Adam,
thank your for your review.
We just published
https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08 that
hopefully resolves your DISCUSS and COMMENT.
> On 4. Sep 2019, at 09:44, Adam Roach via Datatracker wrote:
>
> Adam Roach has entered the following ballot
er for the access token
passed in the introspection request. This identifier MUST be
stable for all introspection calls for a given access token.
---
I hope this resolves your issue regarding non-repudiation.
best regards,
Torsten.
> On 4. Sep 2019, at 11:21, Torsten
t; Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt
> Date: 21. September 2019 at 12:47:28 CEST
> To: "Nat Sakimura" , "Brian Campbell"
> , "Torsten Lodderstedt"
> , &
this draft.
We look forward to getting your feedback.
kind regards,
Torsten.
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
> Date: 21. September 2019 at 16:10:48 CEST
> To: "Jus
pping such parameters between
different devices is the important attack vector. I will improve the text.
best regards,
Torsten.
>
> Best Regards,
> Janak Amarasena
>
> On Sat, Sep 21, 2019 at 11:21 PM Torsten Lodderstedt
> wrote:
> Hi all,
>
> I just published a dra
e of a confidential client,
authenticated in the pushed authorization request.
best regards,
Torsten.
>
>
> Best Regards,
> Janak Amarasena
>
> On Sat, Sep 21, 2019 at 4:32 PM Torsten Lodderstedt
> wrote:
> Hi all,
>
> I just published a new draft that Brian Campb
> On 23. Sep 2019, at 20:22, Brian Campbell
> wrote:
>
> That should probably be fixed unless the example was intended to be set
> nearly 48,000 years* in the future.
>
>
> * assuming my math is correct and you know the old saying about assuming
Haha. You both seem to have a bias towards
this is the
> case I think it might be good to mention this in the spec with something like
> "The authorization server MAY decided to omit the validation of the
> authorization request if the uri sent in the request_uri parameter belongs to
> the authorization server."
Hi Vladimir,
> On 24. Sep 2019, at 08:03, Vladimir Dzhuvinov wrote:
>
> When implementing 08 a question came up:
>
> * The token has multiple audiences (aud), e.g ["rs1", "rs2", "rs3"].
>
> * The RS "rs1" is in the expected audience.
>
> Are there any considerations (privacy, etc) about retur
I wouldn't call it an API. What about just calling it an "HTTP endpoint"?
> On 30. Sep 2019, at 07:52, Brian Campbell wrote:
>
>
>
> On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki wrote:
> > The pushed authorization request endpoint shall be a RESTful API
>
> I would drop the term RESTful and
What if PAR would use another parameter? It could even return the actual
authorization URL.
> On 30. Sep 2019, at 08:45, Brian Campbell
> wrote:
>
>
>
> On Thu, Sep 26, 2019 at 10:50 AM Justin Richer wrote:
>> If, for whatever reason, it is required that this value is
>> actually a URI, is
Hi chairs,
I would like to request the following slots:
- https://tools.ietf.org/html/draft-lodderstedt-oauth-rar
- https://tools.ietf.org/html/draft-lodderstedt-oauth-par
- Security BCP
kind regards,
Torsten.
> Am 04.10.2019 um 11:08 schrieb IETF Meeting Session Request Tool
> :
>
>
>
> A
>
> This is absolutely something that needs to be mentioned in the
> security & privacy considerations.
>
> My worry is that by leading with an example of account numbers in the
> request URL, we're sending the wrong message.
>
> I do see the value in rich authorization requests with no PII like
ry the JWT introspection response to the RS (just
beside the header carrying the cert fingerprint)
best regards,
Torsten.
>
>
>
> On Fri, Sep 20, 2019 at 2:28 PM wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>
ustin Richer
>>>
>>> Bespoke Engineering
>>> +1 (617) 564-3801
>>> https://bspk.io/
>>>
>>>
>>>
>>>> On Sep 24, 2019, at 1:45 PM, George Fletcher wrote:
>>>>
>>>> Just two questions...
>>>>
>&g
Hi,
I’m interested.
kind regards,
Torsten.
> On 15. Oct 2019, at 17:44, Hannes Tschofenig
> wrote:
>
> Hi all,
>
> we would like to hold a virtual interim meeting to discuss the next steps
> regarding the OAuth 2.0 Security Best Current Practice
> (https://datatracker.ietf.org/doc/draft
Hi Dick,
Justin asked me to shed some light on the rationale and current status of the
work on OAuth Rich & Pushed Authorization Requests. I think I will need 20 min.
best regards,
Torsten.
> On 28. Oct 2019, at 16:39, Dick Hardt wrote:
>
> Hey OAuthers
>
> As chair of the Tx BOF coming up
+1
> On 30. Oct 2019, at 14:24, Justin Richer wrote:
>
> All of these problems can be solved, and I think solved better, by securing
> the connection between the proxy and the back-end. That way the back end will
> be able look not only for a specific header, but verify that the header came
>
> On 30. Oct 2019, at 14:56, Neil Madden wrote:
>
> On 30 Oct 2019, at 13:24, Justin Richer wrote:
>>
>> All of these problems can be solved, and I think solved better, by securing
>> the connection between the proxy and the back-end. That way the back end
>> will be able look not only for
1 - 100 of 1141 matches
Mail list logo
