Find bellow my review of the draft:
1. Redactional changes:
2.2. Authorization Data Types
Interpretation of the value of the "type" parameter, and the object
elements that the "type" parameter allows => allowed
9. Metadata
which is an
JSON array. => which is a JSON array
1
igher security level, especially cryptographically confirmed
>non-repudiation, to explicitly adopt JWT-based request objects.
>
> This is what I am looking for. I did oversee this block? Thanks.
/Francis
>
> On Tue, Aug 11, 2020 at 4:27 PM Francis Pouatcha 40adorsys...@dmarc.ietf..org &
gt; On Fri, Jul 31, 2020 at 5:01 PM Francis Pouatcha 40adorsys...@dmarc.ietf.org> wrote:
>
>> Bellow is the only remark I found from reviewing the draft draft:
>>
>> 2.1. Request:
>>
>> requires the parameters "code_challenge" and "code_challenge
o send each authz
request to the TFP for validation.
Best regards,
--
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
f are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Francis
rly a risk here because RAR is pitching itself as a
>> way to do payment transactions.
>> >
>> > The problem is the backchannel request, not RAR. RAR is just a more
>> elaborated scope.
>>
>> I don’t agree. It’s particularly
t a more
> elaborated scope.
>
> I don’t agree. It’s particularly acute with backchannel requests, but it
> still exists with front channel. If I can redirect your browser to a
> payment confirmation screen, what percentage of users will click ok?
The client secret is also a variant of PoP.
This does not change the value of this sentence: "*refresh_token shall
always be bound to a PoP*".
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
___
>
> — Justin
>
> On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt <
> torsten=40lodderstedt@dmarc.ietf.org> wrote:
>
> That’s correct for confidential clients.
>
> For a public client, the refresh token is just bound to the client id.
> DPoP allows bindi
access_token :
-> presenter : Client
-> consumer : RS
-> sender PoP :
--> confidential client: private_key_jwt, mTLS
--> public client: DPoP AND ?
@Daniel Fett I still have some question marks in
here. Am I missing anything?
--
Francis Pouatcha
Co-Founder an
user uninstalls and later reinstalls an app then they can end up with
> multiple registrations for the same client, which makes it harder for them
> to manage access. Additionally, client registrations typically don’t expire
> so the AS doesn’t know when it can remove unused clients.
>
&
deployments.
>
> +1 that’s a very useful
> feature___
>
AFAIK a refresh_token is always bound. What am I missing here?
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
_
t; }
> }
>
This use case is neither multi tenancy nor the disclosure of the client
identity in a consent page. Starting with the logo here, we will end up
adding css and js code snippets. This type of customizing shall be done in
the AS-Deployment without playing around with the public A
> Regarding a token being issued for "personal" vs "business" and
> confusion - the usage of the token is normally defined by its scope and
> audience (RS) and if this rule is observed (and it's not relied solely
> on the issuer URI for that) then clients shoul
e same semantics as their
> current system, but adapted to the syntax of DPoP. i am not in favor of
> this approach, but i am in the minority.
>
> this is long. thanks if you read this far.
>
> -michael thornburgh
>
>
> [1]: https://github.com/solid/authentication-p
gt; >>>>>> Vladimir
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 20/05/2020 15:07, Dave Tonge wrote:
> >>>>>>
> >>>>>>> Dear
0
> compatibility mode to not break existing apps.
>
>
> That is why I support OAuth 2.1 omitting ROPC.
>
>
> Andreas Falk
>
> --
> *From:* OAuth on behalf of Aaron Parecki <
> aa...@parecki.com>
> *Sent:* 12 May 2020 20:19
> *To:* Francis P
king about ROPC mandating OAuth2, but about OAuth-2.1
forbidding the user of ROPC.
> --
> Jim Manico
> @Manicode
>
> On May 11, 2020, at 11:00 PM, Francis Pouatcha 40adorsys...@dmarc.ietf.org> wrote:
>
>
> I am against OAuth 2.1 discarding the use of ROPC (Resource Owner
ed to the
oAuth Client.
/Francis
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200510/8873117a/attachment.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
>
>
> Am 09.04.20 um 09:55 schrieb Rob Otto:
> > I'd imagine you have to pre-register each client and then use HOTP or
> > TOTP to generate one-time passcodes.?
> >
>
> I can come up with a couple of other ways as well, but I'm interested to
> hear what Francis sees "in the wild".
There are many w
URI
> matching, which should help simplify the AS, since simple string matching
> is sufficient now.
>
Not sure it is a good idea to limit scope oAuth 2.1 on existing
functionality of oAuth 2.0 unless we are planning an oAuth 3.0 soon.
--
Francis Pouatcha
Co-Founder and Technical Lead a
where the
operator of the AS is the same one deploying the mobile App using Direct
Grant.
Not sure it is a good idea to limit scope oAuth 2.1 on existing
functionality of oAuth 2.0 unless we are planning an oAuth 3.0 soon.
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https
sent to the AS through the back channel. This of
course requires the implementation of a new "authorization request
initiation endpoint". The draft-ietf-oauth-par-01 provides a guidance on
how to design this initiation endpoint.
--
Francis Pouatcha
Co-Founder and Technical Lead at ad
als" with full compatibility to RFC 6749.
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
25 matches
Mail list logo
