19, at 13:33, Torsten Lodderstedt
> wrote:
>>
>> Hi Neil,
>>
>>>> On 22. Nov 2019, at 20:50, Neil Madden wrote:
>>>
>>> Hi Torsten,
>>>
>>>> On 22 Nov 2019, at 12:15, Torsten Lodderstedt
>>>> wrote:
>&g
're trying to solve with
> DPoP before we can have a productive conversation how it should work.
We will do so.
>
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> On 11/22/19, 10:51 PM, "Torsten Lodderstedt" wrote:
>
>
>
>> On 22. N
s point, which,
in my option, is the prerequisite for making informed decisions.
>
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> On 11/22/19, 9:37 PM, "OAuth on behalf of Torsten Lodderstedt"
> torsten=40lodderstedt@dmarc.ietf.org> wrote:
>
>
&g
>
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> On 11/22/19, 8:17 PM, "OAuth on behalf of Torsten Lodderstedt"
> torsten=40lodderstedt@dmarc.ietf.org> wrote:
>
>Hi Neil,
>
>> On 22. Nov 2019, at 18:08, Neil Madden wrote:
Hi Neil,
> On 22. Nov 2019, at 20:50, Neil Madden wrote:
>
> Hi Torsten,
>
> On 22 Nov 2019, at 12:15, Torsten Lodderstedt wrote:
>>
>> Hi Neil,
>>
>>> On 22. Nov 2019, at 18:08, Neil Madden wrote:
>>>
>>> I think the phrase &qu
>
> Petteri
>
> Fetch API - https://fetch.spec.whatwg.org/
>
> -Original Message-
> From: OAuth On Behalf Of Torsten Lodderstedt
> Sent: perjantai 22. marraskuuta 2019 10.54
> To: Mike Jones
> Cc: oauth ; Torsten Lodderstedt
> ; Rob Otto
>
> Subject: Re: [OA
Hi Neil,
> On 22. Nov 2019, at 18:08, Neil Madden wrote:
>
> On 22 Nov 2019, at 07:53, Torsten Lodderstedt
> wrote:
>>
>>
>>
>>> On 22. Nov 2019, at 15:24, Justin Richer wrote:
>>>
>>> I’m going to +1 Dick and Annabelle’s questio
anisms for different application types is a cost in
> and of itself.
>
> It's good to understand the tradeoffs.
>
> -- Mike
>
>
> From: OAuth on behalf of Torsten Lodderstedt
>
> Sent: Friday, November 22, 2019 4:20:58 PM
> To: Rob Otto
> Cc: oauth
>
Hi Rob,
> On 22. Nov 2019, at 16:10, Rob Otto
> wrote:
>
> Hi Torsten - thanks for the reply..
>
> Responses in line.
>
> Grüsse
> Rob
>
> On Fri, 22 Nov 2019 at 07:59, Torsten Lodderstedt
> wrote:
> Hi Rob,
>
> > On 22. Nov 2019, at 1
ient authentication and sender constrained tokens.
best regards,
Torsten.
>
> -- Mike
>
> -Original Message-
> From: OAuth On Behalf Of Torsten Lodderstedt
> Sent: Thursday, November 21, 2019 11:54 PM
> To: Justin Richer
> Cc: oau
Hi Rob,
> On 22. Nov 2019, at 15:52, Rob Otto
> wrote:
>
> Hi everyone
>
> I'd agree with this. I'm looking at DPOP as an alternative and ultimately
> simpler way to accomplish what we can already do with MTLS-bound Access
> Tokens, for use cases such as the ones we address in Open Banking;
> On 22. Nov 2019, at 15:24, Justin Richer wrote:
>
> I’m going to +1 Dick and Annabelle’s question about the scope here. That was
> the one major thing that struck me during the DPoP discussions in Singapore
> yesterday: we don’t seem to agree on what DPoP is for. Some (including the
> auth
exact matching of redirect URIs and make then Client/AS specific
> - use PKCE
>
> Hans.
>
>> On Tue, Nov 19, 2019 at 5:58 PM Torsten Lodderstedt
>> wrote:
>>
>>
>> > On 19. Nov 2019, at 17:10, Hans Zandbelt
>> > wrote:
>> >
&g
> On 19. Nov 2019, at 17:10, Hans Zandbelt wrote:
>
>
>
> On Tue, Nov 19, 2019 at 10:38 AM Torsten Lodderstedt
> wrote:
> Hi Hans,
>
> > On 18. Nov 2019, at 04:11, Hans Zandbelt wrote:
> >
> > Hi,
> >
> > Please find
Hi Hans,
> On 11. Nov 2019, at 17:57, Hans Zandbelt wrote:
>
> Hi,
>
> Please find my feedback on page 11-20 below.
>
> Hans.
>
> P14
> 4.2.4 For an RP there should be more explicit text and guidance about having
> a single dedicated immutatable redirect URI per client that "demultiplexes"
> Am 19.11.2019 um 13:39 schrieb Vineet Banga :
>
> Let me restate my original question. I agree with the usage of state for CSRF
> protection, but it can also be used to capture the application state (as
> specified in: [I-D.bradley-oauth-jwt-encoded-state]). I am asking if there is
> any re
Hi Hans,
> On 18. Nov 2019, at 04:11, Hans Zandbelt wrote:
>
> Hi,
>
> Please find my feedback from page 21 onwards below.
>
> Hans.
>
> Overall I would argue there's room for a very concise guidance section that
> says: do this, don't do that, without explanation, just as a reference for
> On 17. Nov 2019, at 05:42, Vineet Banga wrote:
>
>
> On Fri, Nov 15, 2019 at 11:51 PM Torsten Lodderstedt
> wrote:
>
> >> On 16. Nov 2019, at 02:07, Vineet Banga
> >> wrote:
> >>
> >> Just one comment/question at the moment:
>
is is less convenient
and leaks PII.
best regards,
Torsten.
>
> Best regards
>
> Hervé
>
> De : Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Envoyé : lundi 18 novembre 2019 11:39
> À : Robache Hervé
> Cc : oauth@ietf.org
> Objet : [OAUTH-WG] Question r
Hi Hervé,
I assume you want to allow the TPP to send the PSU to the bank’s app on the
same device?
In that case, why don’t you just make the bank’s authorization endpoint URL the
universal link? If the universal link is defined on the smartphone (since the
bank’s app is installed), the redirec
> Am 17.11.2019 um 04:06 schrieb David Waite :
>
> You’ll be audience-scoping either way, so it may make sense to use a
> symmetric algorithm for both. It starts to look like kerberos in HTTP and
> JSON when you squint.
Even if audience restriction is a recommended practice, I‘m not fully sur
> On 16. Nov 2019, at 02:07, Vineet Banga
> wrote:
>
> Just one comment/question at the moment:
> 3.1.1 - Is there any recommendation around leveraging state vs using multiple
> URIs (with exact match) to remember the application state of the client? I
> have seen exploding list of registere
Hi Aaron,
> On 14. Nov 2019, at 21:10, Aaron Parecki wrote:
>
> I read through the authorization code injection section
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.5
> but didn't see a mention of this explicitly...
>
> The guidance in 3.1.1 recommends using PKCE
3.3 seems to discourage it in favour of using the "resource"
> parameter. Do you intend for this parameter to be allowed in conjunction with
> a refresh token?
What would be the use case for passing an authorization details parameter to
the token request with a refresh token? The
wfm
> On 11. Nov 2019, at 18:10, Dick Hardt wrote:
>
> Hello Everyone, see agenda below:
>
> Monday Nov-18-2019 1330
>
> TxAuth Bof Agenda
>
> Introduction and Context Chairs 10 min
>
> Limitations and Feature Requests
>
> Limitations of OAuth Justin 10 min
> Limitations of OAut
Hi Daniel,
> Am 09.11.2019 um 18:44 schrieb Daniel Roesler
> :
>
> I realize that it's open to the authorization server to issue
> authorization codes how they see fit. It just strikes me as odd that
> there's not a lot of guidance around when transparent redirects are
> safe, when user interact
ider
this draft for adoption.
best regards,
Torsten.
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-lodderstedt-oauth-rar-03.txt
> Date: 4. November 2019 at 17:43:01 CET
> To: "Justin Richer" , "Tors
mura" , "Brian Campbell"
> , "Torsten Lodderstedt"
> , "Dave Tonge" , "Filip Skokan"
>
>
>
> A new version of I-D, draft-lodderstedt-oauth-par-01.txt
> has been successfully submitted by Torsten Lodderstedt and posted to the
>
> On 30. Oct 2019, at 15:15, Neil Madden wrote:
>
> On 30 Oct 2019, at 14:05, Torsten Lodderstedt wrote:
>>> On 30. Oct 2019, at 14:56, Neil Madden wrote:
>>>
>>> On 30 Oct 2019, at 13:24, Justin Richer wrote:
>>>>
>>>> All of
> 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
> 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
>
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
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
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
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.
>
>
> 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
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
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
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
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
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."
> 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
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
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
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
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"
> , &
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
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
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 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
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 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
> 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
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
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
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
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
> 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
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 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
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--
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!
>
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
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
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 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 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 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 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
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
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
> 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
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
>>> Thanks
>>>>>
>>>>> V.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <
>>>>> hans.zandb...@zmartzone.eu <m
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
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,
>>
>>
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
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 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
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
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
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:
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
> 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&#
; "amount": "123.50"
> },
> "debtorAccount": {
> "iban": "DE40100100103307118608"
> },
> "creditorName": "Merchant123",
> "creditorAccount": {
> "iban": "DE02100100109307118603"
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
> 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
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
>>
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
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
>
>>
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
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
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
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.
>>
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
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
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
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
+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 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
201 - 300 of 1141 matches
Mail list logo
