Thanks, Brian!
I agree that this is the best course of action at this point.
Regards,
Rifaat
On Wed, May 12, 2021 at 3:02 PM Brian Campbell wrote:
> While I admit to being somewhat partial to the acronym, it's not for any
> sound technical or informational reason. To be honest, before I beca
While I admit to being somewhat partial to the acronym, it's not for any
sound technical or informational reason. To be honest, before I became
enamored with my own perceived cleverness of TMI-BFF, I also thought the
use of "BFF" in the context of the draft wasn't quite appropriate.
At this point,
FWIW, I did align the capitalization in the title, "Token Mediating and
session Information Backend For Frontend" to match the accrom. Somewhat
weak justification, I know, but I was going for the branding effect with
something memorable and (hopefully) funny.
On Tue, May 4, 2021 at 9:03 AM Aaron P
+1 for adoption, I'm impartial to the name
Hans.
On Tue, May 4, 2021 at 11:03 PM Aaron Parecki wrote:
> Okay, I have come around to this idea and agree that we shouldn't use
> "BFF" to refer to this pattern. The only reason I am continuing the
> discussion in this thread is that if we agree we
Okay, I have come around to this idea and agree that we shouldn't use "BFF"
to refer to this pattern. The only reason I am continuing the discussion in
this thread is that if we agree we should avoid the term BFF for this
draft, I would like to see it renamed before it is adopted, to avoid any
conf
+1 Mr. Hardt. BFF aims to avoid access tokens in UA's so TMI-BFF is a
badly branded name that will add confusion.
- Jim
On 5/4/21 11:25 AM, Dick Hardt wrote:
My concern with BFF is that the common meaning is what the document
calls Full BFF -- so what many readers will assume is BFF is not wha
I have made up my own implementations that follow the pattern in the
document.
It keeps the security in the server, and allows the app to call the API
directly rather than through a backend proxy, which impacts latency and CX.
ᐧ
On Tue, May 4, 2021 at 8:27 AM Seán Kelleher wrote:
> Hi all,
>
>
Hi all,
I'd like to hear others' take on Brock Allen's prior comment on the
document:
5) For me personally in all the consulting I've done helping customers use
> OIDC/OAuth over the past 7 years (since OIDC was released) I've never seen
> anyone trying to do it this way. I do believe that some p
My concern with BFF is that the common meaning is what the document calls
Full BFF -- so what many readers will assume is BFF is not what the
document is referring to.
ᐧ
On Tue, May 4, 2021 at 8:03 AM Aaron Parecki wrote:
> I support adoption. I'm also fine with the BFF acronym since it's common
I support adoption. I'm also fine with the BFF acronym since it's common in
the software development world already. If anything, the TMI acronym is the
least strong of the two as it's missing a letter from the full name of the
draft.
Aaron
On Tue, May 4, 2021 at 7:40 AM Dick Hardt wrote:
> I
I'm supportive -- but am concerned with the BFF acronym.
ᐧ
On Mon, May 3, 2021 at 3:00 PM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is a call for adoption for the *Token Mediating and Session
> Information Backend for Frontend* as a WG document:
> https://datatracker.ietf.org/doc/draft-bertocci-
All,
This is a call for adoption for the *Token Mediating and Session
Information Backend for Frontend* as a WG document:
https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
Please, provide your feedback on the mailing list by *May 17th*.
Regards,
Rifaat & Hannes
___
12 matches
Mail list logo
