Re: [OAUTH-WG] TMI BFF - html meta tags over/alternative to discovery

Dick Hardt <> Sat, 15 May 2021 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A72883A112F for <>; Sat, 15 May 2021 08:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6eCxYiue113y for <>; Sat, 15 May 2021 08:41:23 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2AE53A112A for <>; Sat, 15 May 2021 08:41:22 -0700 (PDT)
Received: by with SMTP id t11so2538949lfl.11 for <>; Sat, 15 May 2021 08:41:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pDmAK8T2N9gfc5GSScSBuk09hTgq1frCh20NU7V74Ro=; b=XZNpyp0yR0Re/otFOvn7qB2odbsbRccFKxKyzfKPcAcqaCTgHLBfXO0+dSm4tnKQOK xETb5g95xVYRAeeOoFWTnPngV+Y+Brwa3uDNse8EITg7phR4n0og/B+SdimiMvsRzw3i /V4pJ2x4KXCsiTuxuhso70ZO8X9btFLsb3VPs5mEy9m8TCKMhijvOv6H0TuG8gBEDtAD 2FoHSXQwDOljLd4Uyv8deTzwl9RTbM79sRH5D+qgKQj2cy1gnse4fbkpmip5nvoTlrSh NIDaqp8yZ/LN72ThF7blAMVtmCgf4Li6OQoC2lCxmlXT5mVg8ZIB9Igd1fSiDug3i/Mi WvhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pDmAK8T2N9gfc5GSScSBuk09hTgq1frCh20NU7V74Ro=; b=toxueWwNUBhElGcexYUI6uDJI57/lUbbIAd8QG73ZAKs4RQ9mCEdXCgFTje3Uo7yEg 75H+3JWmv8QauT2a0yoDi0J4dmXTPFjB+02kNvpvFie8d/ou3lZ/TO3f0grX44lTDAcm 9OMvnUKkQs83oRqRqwnYq8hk/DnkkSfecVID98fRe5ZXxyQLlBSj+tE3H4bYe3mU3W8r qgslHJI+sRsM/fMSMMRozPJ+17qEdszAj3QXgrhFKp6msaPvzMBipjtG1EwiBXNE0CJL fJTxiMoE8jo+8EvxRI3VbE77xA+5ARhw63/UMPz2fhqH4onDxgCy/PU17/g/WOVHXccd 7T/A==
X-Gm-Message-State: AOAM530uR72EIfstnVR6gcp3kNJ+sGDZXtLt9SUy8YNdPsxjd5daGVRK UOkuzL3Kzh4VvRcnjTN1+ftZ+BqMl0D7FrFR5WY=
X-Google-Smtp-Source: ABdhPJzeUqxQZKyIZLJfiSKJcObNfUXq2FQfQZQQJ4g69/4wRHsi+z2FZMnAzA2kRMPpB16BiYXElOiANtquai7furw=
X-Received: by 2002:a05:6512:31c2:: with SMTP id j2mr27378202lfe.69.1621093280046; Sat, 15 May 2021 08:41:20 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Sat, 15 May 2021 08:41:09 -0700
Message-ID: <>
To: Filip Skokan <>
Cc: Brian Campbell <>, Vittorio Bertocci <>, oauth <>
Content-Type: multipart/alternative; boundary="0000000000001ae16705c2603122"
Archived-At: <>
Subject: Re: [OAUTH-WG] TMI BFF - html meta tags over/alternative to discovery
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 15 May 2021 15:41:28 -0000

As I said in the meeting, I think this is an interesting idea that is worth

I don’t think we need to resolve this for WG adoption of the document.

On Sat, May 15, 2021 at 8:36 AM Filip Skokan <> wrote:

> Hello Vittorio, Brian, everyone
> This is a followup to my feedback in the TMI BFF interim meeting on April
> 26th where I mentioned I'd bring this to the list for discussion.
> I proposed an alternative to using fixed endpoint locations and/or
> discovery. HTML <meta> Tags <>.
> These would be in the returned page HTML's head tag, e.g.
> <meta name="oauth-bff-token" content="/api/bff-token">
>> <meta name="oauth-bff-sessioninfo" content="/api/bff-sessioninfo">
> The javascript SDK handing TMI BFF would know to look for these defined
> meta tags to source the location of the different endpoints. I think this
> could be the primary place an SDK would look at as it doesn't require any
> upfront external requests.
> For the SDK this is as simple as
> var bffTokenPath =
>> document.querySelector('meta[name="oauth-bff-token"]').content;
> If this was the only mechanism defined by the document (to be bashed) I
> think it can save the group a lot of time defining a client discovery
> document which would be otherwise needed. If discovery as an alternative
> solution is indeed inevitable, it can be a second in line mechanism the
> javascript SDK would know to use.
> As discussed in the interim, a well known set of endpoints (or even a
> single root client discovery document) might not always be available for
> control to the webpage depending on where and how it is hosted, on the
> other hand the HTML it serves always, I hope, is.
> Best,
> *Filip Skokan*
> _______________________________________________
> OAuth mailing list