[OAUTH-WG] Re: draft-ietf-oauth-browser-based-apps-20 references

[Aaron Parecki <[e-mail]>]

Thanks Rifaat,

I just published a new version that fixes these references:

https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/21/

Aaron


On Thu, Dec 19, 2024 at 11:43 AM Rifaat Shekh-Yusef <[e-mail]>
wrote:

> Hi Philippe, Aaron,
>
> Few comments on the references:
>
> It looks like you have two unused references: RFC5116 and RFC9207.
> Please, remove them if they are no longer needed.
>
>
> I think the following references should be moved to the normative
> reference section:
>
> *RFC8707*
> Section 9.1 has the following bullet point:
>
>> Use [RFC8707] to restrict access tokens to a single resource
>
>
> *RFC9449*
> Section 6.3.4.2.2 has the following text:
>
>> Browser-based OAuth clients can implement DPoP [RFC9449
>> <https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-20.html#RFC9449>] to
>> transition from bearer access tokens and bearer refresh tokens to
>> sender-constrained tokens.
>
>
> *serviceworker*
> Section 8.2 has some normative text around storage of tokens:
>
>> When aiming to isolate tokens from the application's execution context,
>> the Service Worker MUST NOT store tokens in any persistent storage API that
>> is shared with the main window.
>
>
> *WebMessaging*
> Section 6.3.3.3 has some normative text
>
>> To guarantee confidentiality and authenticity of messages, both the
>> initiator origin and receiver origin of a postMessage MUST be verified
>> using the mechanisms inherently provided by the postMessage API (Section
>> 9.3.2 in [WebMessaging]).
>
>
>
> Thoughts?
>
> Regards,
>  Rifaat
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>