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

Brian Campbell <> Mon, 17 May 2021 20:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB4343A42FC for <>; Mon, 17 May 2021 13:04:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kCiGBX3B4iw2 for <>; Mon, 17 May 2021 13:04:00 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B71EE3A42FF for <>; Mon, 17 May 2021 13:03:59 -0700 (PDT)
Received: by with SMTP id e11so8726362ljn.13 for <>; Mon, 17 May 2021 13:03:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c+Yp0Fd/AQRHE33CgmgQQFV3YgFJw7KTxWjoZbaVF3M=; b=a2WJYUSqjpa3q61E69wdfZii46h+ar1q2+KX/53d9hxDzk11K7Zaf0+Bq7Cmlweb55 T72RwVL2d1xrk9MPpJE0OqAJnjtlJa0mt3qEb2H96NOQUpwANbwO21Z8NwNVqHeCs2Az 3Sp2Cu0Xscqf0ti8Q3QEBcCXi/zKngUDR90wuKbGJVfoq04rKl9AL0Tr7cn0ACNw09jH N18krYMP4QQ5sG2xQkbIBO06VFh9nBJevZNo4hX/JyGJMuZe/x9xZ7jR6GapOt+aWcX+ d+mJfg+KbxPDBTeF/PYiNslRzOWOJCiIsTxhdA3OZFTuZ+PVbCdw5z4lSs2nToIxOvj5 ZplA==
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=c+Yp0Fd/AQRHE33CgmgQQFV3YgFJw7KTxWjoZbaVF3M=; b=O8s89rIY6BqUzfZrKURGdTgBc5dLxEegt7t9H2GT3Z30Sd6/G+6T2G1EyXEIpDMF19 DliX/YAjQTy1U7EsT+VbAf0wn0B54iIUx5dSpbYKUglOw9Ol1m2/JDpuhpwxLESzhPbI tGEZlK5o8sbQEx7RShaB8eN830Deq25u1hzeItbbrxg7/f+w4l9qVQQdHkOfiEjjnx/r D5aW/wLqkodQd0fq2MdpU4fQDMdUiPP/WK8M/1Vqt2VKzjVbdw1r0Xhs9GKVCZRDZiJL 60iyV1H5kHkaO2NsgxqIsiWqvMciDvtzHDBnQaZ9BJWrVoagppFCnInqxjRtMpNZFIr9 L2BA==
X-Gm-Message-State: AOAM532hWHO6gcRexTOV8HAW0IbcPW3KFBvgRw3ijdf6xU9yVnfnRgC7 KbDo4NPDlyMi/iWS3AmtbqzC0oFT9rIVM7MG+/y0Fyo43nxuIbNEnn1JgVL3Rv+zg06Fb5G3IyD 6UfOVEpGKCe5ZnwF21dcSdA==
X-Google-Smtp-Source: ABdhPJz1brLDHIKePz/n9ZrDYJvJYVcrAdJWv8U/X5Y3ttcT5A9clpzN6vucE4fodwTynCNW1DYkhwQdsxQ/avHV29A=
X-Received: by 2002:a2e:a594:: with SMTP id m20mr912880ljp.114.1621281836397; Mon, 17 May 2021 13:03:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Mon, 17 May 2021 14:03:30 -0600
Message-ID: <>
To: Warren Parad <>
Cc: Philippe De Ryck <>, Vittorio Bertocci <>, oauth <>
Content-Type: multipart/alternative; boundary="000000000000f091f005c28c170c"
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: Mon, 17 May 2021 20:04:05 -0000

The interim discussion can be found here
but the general context, as I understand it, is that there's a desire to
have the location of the two application endpoints be conveyed to the
frontend in a defined way that avoids out-of-band configuration and also
doesn't infringe on the application namespace. The current draft places the
two endpoints directly in .well-known but a number of folks have stated
reasons that's less than ideal or even unworkable in many common
deployments. Moving to a single static document in .well-known that lists
the endpoint locations is one alternative approach. This thread suggests a
different alternative of placing the locations in HTML meta/link tags or
link headers returned with the application's main html page.

On Sun, May 16, 2021 at 2:04 AM Warren Parad <wparad=> wrote:

> I agree, missing context for this:
> 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.
> Wouldn't this only be used as input to a SDK, why wouldn't you just define
> the configuration in javascript, like everything else?
> Also, is it required or something that can be added later?
> On Sun, May 16, 2021, 09:26 Philippe De Ryck <
>> wrote:
>> Without having the full context of the interim meeting, this feels really
>> off to me. I see the need for making this configurable, but I have doubts
>> about using HTML elements for this purpose.
>> As far as I understand, this mechanism is supposed to be used for modern
>> frontends (Angular, React, …). Having to add variables to the index.html in
>> these applications is likely to conflict with their development paradigms.
>> It would be much easier to add these variables to the environment file, so
>> you can differentiate between dev and prod when necessary.
>> Additionally, querying the DOM for API endpoints sounds like a lot of
>> trouble. I don’t think that injection is that big of a risk, but I might be
>> wrong (I’m sure someone said that about the base tag as well). However,
>> using DOM APIs like this will cause headaches for server-side rendering,
>> where these DOM APIs are typically not available (e.g.,
>> ).
>> Kind regards
>> Philippe
>> —
>> *Pragmatic Web Security*
>> *Security for developers*
>> On 15 May 2021, at 17:35, 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
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list

_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._