Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

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 >

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

n 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+1, Torsten Lodd

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

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

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

hould 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 >&

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

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 have seen so far

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

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 >>> &

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

e > 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 the frontend

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

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: >

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

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

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

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

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

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

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

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. >>

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

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

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

nd intended 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: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt

> 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. So

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt

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, >> >>

Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

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 response t

Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

> 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

Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

h bound tokens. Yes both have keys but it is better to describe > them separately. > > John B. > > On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab > Hi Nat, > > I understand you are saying your draft could provide clients with an > application lev

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Nat, I understand you are saying your draft could provide clients with an application level mechanism to sender constrain access tokens. That’s great! But I don’t see a binding to response type „token id_token“. Why do you want to expose the tokens via the URL to attackers? You could

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

. FWIW I am reallly happy to see this happening. > Quick question though. What is the recommendation about dealing with the > client secret in this situation? > > regards > > antonio > From: OAuth on behalf of Torsten Lodderstedt > > Sent: Sunday, November 25, 2018

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

nt type. > > > I do not know if anybody is using Implicit with Confidential clients, but > just in case, you might want to make it clear that your recommendations are > specifically for public clients. > > Regards, > Rifaat > > > > >> On S

Re: [OAUTH-WG] Binding Access Tokens is not enough!

Does this mean the RS effectively relies on the user agent to enforce the sender constraint (via CORS policy)? > Am 23.11.2018 um 14:54 schrieb Neil Madden : > > Thanks for doing this Daniel, I think the proposed text is good. > > — Neil > >> On 22 Nov 2018, at 14:42, Daniel Fett wrote: >>

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Rifaat > > > On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt > wrote: > Hi all, > > I would like to state again what the proposal of the authors of the Security > BCP is: > > Here is the respective text from the draft: > > —— > > 2.

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

karounds on this thread. > > Hans. > > [1] > https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/ > > On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt > wrote: > that’s certainly true, but that might by a web server with stati

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

a backend because it has to be loaded from somewhere :) > >> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote: >> We had a discussion about this topic on Twitter >> https://twitter.com/Apl3b/status/1064854507606208513 >> >> Outcome is POST requires a backend to re

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

tunately it doesn't do anything to protect against leakage in logs or >> redirects. >> >> So without the AT using some sort of POP mechanism it is hard to say sending >> it in a redirect is a good security practice. >> >> John B. >> >> On 11/2

Re: [OAUTH-WG] Token Binding & implicit

I opt for (4) - Remove support/description of binding of access tokens issued from the authorization endpoint I think the potential solution we worked out (slide 6) is to complex and the security implications of the redirect via the resource servers are still unclear. > Am 18.11.2018 um

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt

ailable from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > >Title : OAuth 2.0 Security Best Current Practice > Authors : Torsten Lodderstedt >

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Mike, I agree that OIDC hybrid flows offer additional security over the OAuth implicit grant and are used in the wild. On my slides and in the initial version of the new section, we had included the hybrid OIDC flows because of their known token injection countermeasures. I nevertheless

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

10:59 AM Vladimir Dzhuvinov >> wrote: >>> On 17/11/2018 13:26, Torsten Lodderstedt wrote: >>> To start with, the AS may use refresh token rotation in combination with >>> automatic revocation in case of detected replay attempts. >>> >&

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

Hi Tomek, > Am 16.11.2018 um 13:59 schrieb Tomek Stojecki : > > >> The AS can bind the lifetime of the refresh tokens to the session > >> lifetime, i.e. automatically revoke it on logout. > > > Yea, I saw your other email asking about refresh token revocation relating > > to session

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

u were always on the „make it secure“ side, I’m a bit surprised. kind regards, Torsten. > > > > Best, > > > > Nat Sakimura > > > > From: OAuth On Behalf Of Brock Allen > Sent: Friday, November 16, 2018 7:01 AM > To: Torsten Lodderstedt > Cc

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

Hi Brock, > Am 15.11.2018 um 23:01 schrieb Brock Allen : > > > It still lacks the ability to issue sender constraint access tokens. > > 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 >

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

Hi Brock, > Am 15.11.2018 um 15:01 schrieb Brock Allen : > > > Helps to prevent leakage, not injection in the authorization response. > > So then wording and its motivation could get updated to correctly reflect > that. > > >> "OAuth 2.0 provides no mechanism for a client to verify that an

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.txt

Hi, here is the respective text proposal for section 2.1. (Note: we also refactored the text in order to disentangle CSRF/replay and mix-up detection). Clients MUST prevent CSRF and ensure that each authorization response is only accepted once. One-time use CSRF tokens carried in the

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

Hi Brock, > Am 09.11.2018 um 21:22 schrieb Brock Allen : > > Hello all -- > > I also have some thoughts/feedback on this document. > > Personally I agree with some of the conclusions, but as it stands I think the > document's main conclusion that code flow is the real solution is not >

Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-mtls

Hi Evan, I scanned through the SPIFFE docs but didn’t any mentioning of OAuth (just plain X.509). What’s your plan for introducing OAuth and mtls? kind regards, Torsten. > Am 13.11.2018 um 00:59 schrieb Evan Gilman : > > Thank you everyone for the feedback. > > I am currently working on

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.txt

have a stronger requirement on client authentication that should be fine. Question to the list: what is your implementation experience regarding one time use authorization codes? Thanks for your feedback! kind regards, Torsten. > > > Cheers, > > Joseph > > &g

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

> Am 08.11.2018 um 22:59 schrieb David Waite : > > PCKE does not resolve any known code injection attacks for SPA public clients. It can be utilized to detect code injection at the redirect between AS and client. The PKCE verifier is bound to user agent that initiated the corresponding

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.txt

. I also posted about this topic on LinkedIn (https://www.linkedin.com/pulse/why-you-should-stop-using-oauth-implicit-grant-torsten-lodderstedt/) and Medium (https://medium.com/@torsten_lodderstedt/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926) kind regards, Torsten. >

[OAUTH-WG] OAuth Security Workshop 2019 - Save the Date!

Hi all, it has become a tradition to conduct an OAuth Security Workshop once a year. This time it is taking place March 20–22, 2019 (just before IETF-104 in Prague), in Stuttgart/Germany, and is hosted by the Institute of Information Security (SEC) at the University of Stuttgart. And here is

[OAUTH-WG] Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)

Hi all, the Financial-grade API WG at the OpenID Foundation has published a mechanism for signing and encrypting OAuth authorization responses that I would like to bring to your attention. The draft https://openid.net//specs/openid-financial-api-jarm-wd-01.html went already through

[OAUTH-WG] Generalizing draft-ietf-oauth-jwt-introspection-response-01

Hi all, as mentioned during the presentation this morning, I would like to get a feeling what the working groups thinks about generalizing draft-ietf-oauth-jwt-introspection-response-01 to a mechanism supporting requesting and providing JWT responses from the different OAuth endpoints, such

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-08.txt

ty Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Daniel Fett > Filename: draft-ietf-oauth-security-topics-08.txt > Pages

Re: [OAUTH-WG] OAuth WG - Important Dates

Hi chairs, I would like to present two drafts in Bangkok: - draft-ietf-oauth-security-topics - draft-ietf-oauth-jwt-introspection-response I would also like to present to the group a new work item being prepared by the OpenID Foundation FAPI WG: - JWT Secured Authorization Response Mode for

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Hi Samuel, thanks for preparing this draft. I‘ve got one question: how would one use it for non-reputation? I assume non-reputation would require not only to sign the request body but also (at least) data about the target of the request, typically a URL + HTTP method. Would one need to include

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-07.txt

to restrict tokens to a single server. The draft states: „In particular, access tokens SHOULD be restricted to certain resource servers, preferably to a single resource server." > > On 8/27/18 2:24 PM, Torsten Lodderstedt wrote: >> >> >> Am 27.08..2018 um 11:32 sc

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-07.txt

e.g. using the resource parameter introduced by the resource indicators draft). The rest could work like (2) kinds regards, Torsten. > Vladimir >> On 24/08/18 12:57, Torsten Lodderstedt wrote: >> Hi all, >> >> I just published a new revision of the OAuth Security BCP. >

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-07.txt

> >Title : OAuth 2.0 Security Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Daniel Fett > Filename: draft-ietf-oau

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-jwt-introspection-response-01.txt

>Title : JWT Response for OAuth Token Introspection >Authors : Torsten Lodderstedt > Vladimir Dzhuvinov > Filename: draft-ietf-oauth-jwt-introspection-response-01.txt > Pages : 11 > Date

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-00.txt

Hi Brian, here are my text proposals (and a comments): - Section 2, resource parameter definition „It MUST be an absolute URI, as specified by Section 4.3 of[RFC3986], and MUST NOT include a query or fragment component.“ Why does the draft preclude query components? - I would propose

Re: [OAUTH-WG] updated Distributed OAuth ID

2.0). As the only drawback, encoding of resource servers in scopes and refresh token handling to obtain RS-specific access tokens is proprietary. > >> >> In the future, you would like the client to ask for multiple resources that >> are managed by the same AS, correct? >&g

Re: [OAUTH-WG] updated Distributed OAuth ID

re managed by the same AS, correct? > > >> On Tue, Jul 24, 2018 at 1:47 PM, Torsten Lodderstedt >> wrote: >> For every bank (and their customers) there is a set of services run by the >> bank or other entities, which rely on the AS of the particular bank f

Re: [OAUTH-WG] updated Distributed OAuth ID

nformation, payment initiation, identity, and electronic signature > >> On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt >> wrote: >> >>> And who is the AS? >> >> In case of yes, it’s typically the bank. At Deutsche Telekom, it is the >>

Re: [OAUTH-WG] updated Distributed OAuth ID

> And who is the AS? In case of yes, it’s typically the bank. At Deutsche Telekom, it is the central AS/IDP. Why are you asking? > >> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt >> wrote: >> >>> Am 23.07.2018 um 13:58 schrieb Dick

Re: [OAUTH-WG] updated Distributed OAuth ID

> Am 23.07.2018 um 13:58 schrieb Dick Hardt : > > In your examples, are these the same AS? yes > > > >> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt >> wrote: >> Hi Dick, >> >> > Am 23.07.2018 um 00:52 schrieb Dick Hardt : &g

Re: [OAUTH-WG] updated Distributed OAuth ID

Hi Dick, > Am 23.07.2018 um 00:52 schrieb Dick Hardt : > > Entering in an email address that resolves to a resource makes sense. It > would seem that even if this was email, calendar etc. -- that those would be > different scopes for the same AS, not even different resources. That is how >

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10

Hi Rifaat, Berlin Group‘s Nextgen PSD2 Spec (https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf) also refers to mTLS. kind regards, Torsten. > Am 21.07.2018 um 23:25 schrieb Rifaat Shekh-Yusef : > > All, > > The following is the shepherd write-up for the

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"

Hi Mark, > Am 20.07.2018 um 17:47 schrieb Mark Dobrinic : > > I +1 this, thanks > > but at the same time, I'm wondering what happened with the argument that > this should be solved by Token Exchange instead of Introspect? We presented two use case in London, (1) providing evidence for the

Re: [OAUTH-WG] updated Distributed OAuth ID

Hi Dick, Am 19.07.2018 um 15:46 schrieb Dick Hardt : >> I think any scenario with multiple resource servers relying on the same AS >> for authorization where the client acts on behalf of the resource owner >> qualifies for grant type code and distributed OAuth. >> >> Let’s assume a user

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

gt; >> >> >> >> >> >> >> >> On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan wrote: >> >> Hi Torsten, >> >> >> >> > Multiple "resource" parameters may be used to indicate that the i

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"

> Am 20.07.2018 um 16:06 schrieb Anthony Nadalin > : > > I’m concerned over the security implications of a client being able to > introspect a token, for bearer tokens this can be very problematic, so unless > the issues with possible token theft can be addressed I don’t support this as > a

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

I support adoption of this document. I would like to point out (again) a single resource is not sufficient for most use cases I implemented in the last couple if years. I‘m advocating for enhancing the draft to support multiple resources and a clear definition of the relationship between

Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"

+1 > Am 20.07.2018 um 08:21 schrieb n-sakimura : > > And if it were not obvious, YES J > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Dick Hardt > Sent: Friday, July 20, 2018 6:12 AM > To: Rifaat Shekh-Yusef > Cc: oauth > Subject: Re: [OAUTH-WG] Call for adoption for

Re: [OAUTH-WG] updated Distributed OAuth ID

Hi Dick, > >> >> Section 3: >> Don’t you think it could be a useful information to have the resource URI >> available in the authorization flow?I would assume it could have some >> additional meaning to the AS and could also be the context of the scope. > > I'm assuming you are referring

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-00.txt

Hi William, I think it would make sense to add AS metadata fields, which the AS can use to advertise support for include_granted_scopes and existing_grant. kind regards, Torsten. > Am 17.07.2018 um 19:33 schrieb William Denniss : > > Hi Torsten, > > On Tue, Jul 17, 2018 at 7

Re: [OAUTH-WG] updated Distributed OAuth ID

Hi Dick, I like the draft! It puts together some best practices relevant for dynamic OAuth in a reasonable way. Some comments: Section 2: I appreciate the idea to let the resource determine its resource URI (later used as aud of the access token). This will allow the RS to segment and group

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-00.txt

Hi Dick, I gave you draft a read and came up with the following questions: Section 2: How does Party A know it is supposed to conduct a reciprocal OAuth flow if Party B does not indicate so in the authorization response? Section 3 Party A is supposed to call the token endpoint of Party B

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-00.txt

Hi William, please find below my review feedback. First of all, I think you managed to come up with the minimal extension needed to address a very relevant use case. Thanks! - Section 5, last paragraph. "the new refresh token issued in the Access Token Response (Section 4.1.4 of ) SHOULD

Re: [OAUTH-WG] MTLS - IPR Disclosure

I’m not aware of any IPR re the OAuth mTLS draft. > Am 17.07.2018 um 16:11 schrieb Nat Sakimura : > > Not that I am aware of. > > On Tue, Jul 17, 2018 at 11:06 PM Rifaat Shekh-Yusef > wrote: > Authors, > > As part of the write-up for the OAuth MTLS document, we need an IPR > disclosure

Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata is now RFC 8414

Congratulations! > Am 28.06.2018 um 18:15 schrieb William Denniss > : > > Congratulations! > > Really glad that we have an RFC specifying how servers should provide their > configuration data in machine readable form. Helps with developer experience > (less manual configuration), as well as

Re: [OAUTH-WG] Dynamic Scopes

ace to start. > > Thanks, > George > > -- > Identity Standards Architect > Identity Engineering > Oath > >> On Jun 27, 2018, at 12:22 PM, Torsten Lodderstedt >> wrote: >> >> Hi George, >> >> thanks a lot for investing the time to a

Re: [OAUTH-WG] Dynamic Scopes

: user meets required claims > A-->B: redirect > B->I: user met claimns\n(permission tckt) > I->A: request RPT\n(permission tckt) > A->I: RPT issued > I->S: sign doc\n(RPT) > S->A: introspect\n(RPT) > A->S: permissions\n(required params) > S->I:

Re: [OAUTH-WG] Dynamic Scopes

red here] > > I think it's worth exploring whether UMA will solve this use case. > > Thanks, > George > > [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html > >> On 6/23/18 3:43 AM, Torsten Lodderstedt wrote: >> >>> Am 22.06.2

Re: [OAUTH-WG] Dynamic Scopes

not an intended recipient, please notify the sender and > delete this e-mail. > From: OAuth on behalf of Torsten Lodderstedt > > Sent: Saturday, June 23, 2018 3:43:50 AM > To: George Fletcher > Cc: Brian Campbell; oauth > Subject: Re: [OAUTH-WG] Dynamic Scopes > >

Re: [OAUTH-WG] Dynamic Scopes

> Am 22.06.2018 um 23:08 schrieb George Fletcher : > > I would think that the scope issued to the refresh_token could represent the > category or class of authorizations the refresh_token should be able to > perform. For example, the kind of transactions that can be bound to access > tokens.

Re: [OAUTH-WG] Dynamic Scopes

is >> blurring the line between authorization and authentication a bit much. Also, >> as others have pointed out, OIDC isn't always in play - particularly for >> regular old authorization cases. >> >> An additional query parameter might be simple for a one-off case but

Re: [OAUTH-WG] Dynamic Scopes

n play - particularly for > regular old authorization cases. > > An additional query parameter might be simple for a one-off case but it's > nonstandard and not very repeatable. > > > On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt > wrote: > Hi all, > &

Re: [OAUTH-WG] Dynamic Scopes

Hi Jacob, thanks for your thoughts on dynamic scopes. > Am 19.06.2018 um 08:16 schrieb Jacob Ideskog : > > For OpenID I still think the signed claims parameters make a more flexible > approach, but OpenID isn't always in play. Why do you think it is more flexible? kind regards, Torsten.

[OAUTH-WG] Dynamic Scopes

Hi all, I have been working lately on use cases where OAuth is used to authorize transactions in the financial sector and electronic signing. What I learned is there is always the need to pass resource ids (e.g. account numbers) or transaction-specific values (e.g. amount or hash to be signed)

Re: [OAUTH-WG] draft-ietf-oauth-security-topics

ril 2018. thanks for pointing this out. My local environment somehow fetched outdated data. It's been corrected now. FROM mtls-07 (work in progress), January 2018. TO mtls-08 (work in progress), May 2018. FROM tokbind-https-12 (work in progress), January 2018. TO tokbind-https-14 (work in progr

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

Hi Johan, thanks for your proposal. I’m not sure whether it should go to 3.7.1.4. The reason audience restriction turns up as a subsection of 3.7 is our document is organized by attacks instead of security controls. I could image to add a section on audience/action restriction as sub section

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-01.txt

rsten. > > Thanks, > George > > On 5/28/18 12:58 PM, Torsten Lodderstedt wrote: >> Hi all, >> >> I just published a new revision of the JWT Introspection response draft. >> Based on the feedback in London, the draft entirely focuses on use cases >

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

Hi Neil, > Am 25.05.2018 um 12:49 schrieb Neil Madden <neil.mad...@forgerock.com>: > > Hi Torsten, > >> On 25 May 2018, at 10:35, Torsten Lodderstedt <tors...@lodderstedt.net> >> wrote: >> >> Hi Neil, >> >>> Am 28.03.2018 um 17

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

introspection endpoint fills the gap between the > two specifications. > > > Best regards, > Petteri Stenius > > [1] > https://datatracker.ietf.org/meeting/101/materials/slides-101-oauth-sessb-jwt-introspection-response-01 > > > > From: OAuth <o

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

onse could be abused as ID Token other than the recipient of the response (or an attacker able to obtain the response object) sets up a fake IDP and provides the response as an ID token to a RP. The RP should be able to detect this (as other ways to replay ID tokens) by utilizing the nonc

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-06.txt

OAuth 2.0 Security Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Daniel Fett > Filename: draft-ietf-oauth-security-topics-06.txt &g

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental Authorization

+1 > Am 24.04.2018 um 05:33 schrieb Nat Sakimura : > > +1 > > On Thu, Apr 19, 2018 at 3:28 AM Richard Backman, Annabelle > > wrote: > I support adoption of OAuth 2.0 Incremental Authorization as a WG document. > > > > --

Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12

- Mike > > From: OAuth <oauth-boun...@ietf.org> On Behalf Of Brian Campbell > Sent: Wednesday, April 18, 2018 8:17 AM > To: Torsten Lodderstedt <tors...@lodderstedt.net> > Cc: oauth <oauth@ietf.org> > Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-ex

Re: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-05

Hi Phil, thanks for reviewing it. We incorporated the respective changes in the upcoming -06. best regards, Torsten. > Am 22.03.2018 um 10:52 schrieb Phil Hunt : > > Torsten, > > Great document! > > Some minor nits and comments: > > Abstract - double period after

[OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12

Hi all, I I’m wondering why draft-ietf-oauth-token-exchange-12 defines a claim „scp“ to carry scope values while RFC 7591 and RFC 7662 use a claim „scope“ for the same purpose. As far as I understand the text, the intension is to represent a list of RFC6749 scopes. Is this correct? What’s the

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

Hi all, thanks for your feedback. Here is my text proposal for section 3.8.1. —— Attackers could try to utilize a user's trust in the authorization server (and its URL in particular) for performing phishing attacks. RFC 6749 already prevents open redirects by stating the AS MUST NOT

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

Hi Brian, > Am 20.03.2018 um 15:37 schrieb Brian Campbell : > > +1 to what Travis said about 3.8.1 > > The text in 3.8 about Open Redirection is new in this most recent -05 version > of the draft so this is really the first time it's been reviewed. I believe >

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

-cavage-http-signatures-09>) could not >> meet this requirement in a more generic way ? >> >> Regards, >> Louis >> >> De : OAuth <oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>> De la >> part de Brock Allen >> Envoyé : diman

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

se. kind regards, Torsten. > > -Brock > >> On 3/18/2018 3:33:16 PM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: >> >> Hi all, >> >> I just submitted a new draft that Vladimir Dzhuvinov and I have written. It >> proposes a JWT-based r

[OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

8. März 2018 um 20:19:37 MEZ > An: "Vladimir Dzhuvinov" <vladi...@connect2id.com>, "Torsten Lodderstedt" > <tors...@lodderstedt.net> > > > A new version of I-D, > draft-lodderstedt-oauth-jwt-introspection-response-00.txt > has been successful

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

ty Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Filename: draft-ietf-oauth-security-topics-05.txt > Pages : 27 > Date: 2018-03-18

Re: [OAUTH-WG] IETF101 Draft Agenda

ON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015. [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015. [OpenID.Registration] NRIPing IdentityMicrosoft, "OpenID Connect Dynamic Client Registration

<    1   2   3   4   5   6   7   8   9   10   >