Hi Aaron,
Thx for your suggestions. I have reviewed the recordings and I would
suggest following:
1. Design Consideration: The two components of the OAuth 2.0 ecosystem
authorization server (step 1) and protected resource server (step 2) may
appear independent, but from systems perspective there
Hi Jaimandeep,
As with many OAuth extensions, this is not obligatory to implement unless
you need the functionality it provides. Many of the concerns you mention
are referenced in the security considerations section of the draft already,
and we would of course be happy to further expand that
I just happened to notice this and given the title of the draft, "Federated
Authentication for the Registration Data Access Protocol (RDAP) using
OpenID Connect" thought it might be of interest to some in the OIDC or
OAuth working groups (both cc'd). I don't have the cycles (or energy to be
I support adoption
On Aug 23, 2023, at 3:01 PM, Rifaat Shekh-Yusef
wrote:
All,
This is an official call for adoption for the Protected Resource
Metadata draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
Please, reply on the mailing list and let us know if
I do not support the adoption because of following:
1. Increased Attack Surface and Information Disclosure: The proposed draft
inherently expands the attack surface by allowing the retrieval of detailed
information about the protected resources held with a particular resource
server, as outlined
Hi everyone,
The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract
further explains that it "details the security considerations and best
practices that must be taken into account when developing browser-based
applications that use OAuth 2.0.".
As such, detailing security
I support adoption.
> On 23 Aug 2023, at 20:02, Rifaat Shekh-Yusef wrote:
>
>
> All,
>
> This is an official call for adoption for the Protected Resource Metadata
> draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let
I support adoption
On Wed, Aug 23, 2023 at 3:02 PM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
I support adoption
On Fri, Aug 25, 2023 at 5:09 PM John Bradley wrote:
> I support addoption
>
> On Aug 23, 2023, at 3:01 PM, Rifaat Shekh-Yusef
> wrote:
>
> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
>
I support addoption
> On Aug 23, 2023, at 3:01 PM, Rifaat Shekh-Yusef
> wrote:
>
> All,
>
> This is an official call for adoption for the Protected Resource Metadata
> draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and
Inline:
On Thu, Aug 24, 2023, 6:50 PM Watson Ladd wrote:
> On Thu, Aug 24, 2023, 1:32 PM Kristina Yasuda
> wrote:
> >
> > First of all, BBS and SD-JWT are not comparable apple to apple. BBS is a
> signature scheme and it needs to be combined with few other things like JWP
> or BBS data
Second, how to do batch issuance of the credential (honestly, of any credential
format: not just SD-JWT VCs but also mdocs and JWT-VCs) and whether it can be
done low cost is out of scope of the credential format (or any of its
components) specification itself. Btw when using OpenID4VCI (an
--
null
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Download and install please
On Thu, Aug 24, 2023 at 6:50 PM wrote:
> Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject
14 matches
Mail list logo
