From nobody Tue Jan 26 14:12:06 2021
Return-Path: <me@evertpot.com>
X-Original-To: httpapi@ietfa.amsl.com
Delivered-To: httpapi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id E35113A017E
 for <httpapi@ietfa.amsl.com>; Tue, 26 Jan 2021 14:12:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5
 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
 DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001,
 SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key)
 header.d=evertpot.com header.b=axamcusc;
 dkim=pass (2048-bit key)
 header.d=messagingengine.com header.b=ecWo4/9a
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id xRTFAWfJa87o for <httpapi@ietfa.amsl.com>;
 Tue, 26 Jan 2021 14:12:03 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com
 [64.147.123.20])
 (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id BAEB23A00D2
 for <httpapi@ietf.org>; Tue, 26 Jan 2021 14:12:03 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
 by mailout.west.internal (Postfix) with ESMTP id AFD439F0
 for <httpapi@ietf.org>; Tue, 26 Jan 2021 17:12:02 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute3.internal (MEProxy); Tue, 26 Jan 2021 17:12:02 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h=
 subject:to:references:from:message-id:date:mime-version
 :in-reply-to:content-type; s=mesmtp; bh=oDC1AzZ3wjTvYzjI+mdrSvI9
 2QIGogVA3QhYDjCVCgs=; b=axamcuscruckul+2jCA2OEbvKFDXjZaQzdXobreL
 UlkStBtfrW3ZKpKZ5Fga3hDvH7NcRQudpKb0BZ3aWhKCFhZb58mnORQZ+fmSzwGI
 3lxnEgjKYS8LqnL6CTFzsDH6tTDBuiNDHHpvM51Q1dRDxcw+tk/XcEhWiIvRiip6
 c+w=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=oDC1Az
 Z3wjTvYzjI+mdrSvI92QIGogVA3QhYDjCVCgs=; b=ecWo4/9ax2OdwaepbTa5/n
 NxakQi3TL4kwdCatNv+T/AfPq68qDv/vxwqilE1UX4HTkz6Cf+4l5WRIXlnDRGDJ
 FKnILnfV0nOkFGoPRvh3VCcJzQevLfDsRyIVkW+GhgPypLBGIb2gAQqlZLcQsQHj
 J3saBpKmJfRniA4qYjNEBvIFkvKPdOJmv5V3K2sXWinRsBommsahgPumIbxbe/aZ
 vLVus7JVRhUgQ5dAQDiso8f75LwifI+9zI66K7aGDJX/Fved/Teu4sQSewsWgyT1
 PG50wnaDOtNbOES8JdPX95cjuC7Uc+iF/LXGcBr2I9v64d4Us7ZJQqqA1EHi6EdA
 ==
X-ME-Sender: <xms:sJMQYNWDZo4aRR8BpIHOU6GA7TiceVWY2VSFhHpCReClemW3J5I_RQ>
 <xme:sJMQYNmbaUKkhkxbo9aNkqU3ZwTcWydSzzu97SwyNq3G7QbbKaLAMeREOFtzaTuaw
 nV-y37ov0rvCJCw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeigdeliecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderre
 dtfeejnecuhfhrohhmpefgvhgvrhhtucfrohhtuceomhgvsegvvhgvrhhtphhothdrtgho
 mheqnecuggftrfgrthhtvghrnheptefhkeefledvjeduueegueeggfetieehiedvvddttd
 ehledvtdegudfhleehiedtnecukfhppedugedvrdduvdeirdduieeirddvtdejnecuvehl
 uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgvsegvvhgvrh
 htphhothdrtghomh
X-ME-Proxy: <xmx:sJMQYJapaPpR6eFYERaSKOFZgzNwu47eOMscZ4z35IbWo4xGbHleXg>
 <xmx:sJMQYAVlGFYjIdf5vGsORkg6z6TN4B0oEjDb2T-zJt9PXu3eBAc5AA>
 <xmx:sJMQYHlFBUarExqYFXSv1sAdhDxDE68fFjQH88xgX8DExl1aJJauxg>
 <xmx:sZMQYDy0MewuRSyVIj8C_l2P9GXF9Tadm1Fh7ex32eKoUrL-2aYQ0A>
Received: from [192.168.2.63] (unknown [142.126.166.207])
 by mail.messagingengine.com (Postfix) with ESMTPA id B8DAE240064
 for <httpapi@ietf.org>; Tue, 26 Jan 2021 17:12:00 -0500 (EST)
To: httpapi@ietf.org
References: <CAO0N9X4TTcQTk_Nrd9hYCs3wFkx6pNfsXaig7BVFzvVFQU-1+Q@mail.gmail.com>
 <DM6PR00MB08458672E57AACC3BB8367EEF0BC9@DM6PR00MB0845.namprd00.prod.outlook.com>
 <CAP9qbHXLep=+5dBxqSh829PSkKVjxcEnRn6XHWcRdgQrHc9uAA@mail.gmail.com>
 <e0db5e86-0b68-7b9a-b9c5-ea12745aab93@evertpot.com>
 <CAPBurBvUuQZigMCPHu3h5FhyNJDJauzZQdWbNR2R5yxWO9R_4w@mail.gmail.com>
From: Evert Pot <me@evertpot.com>
Message-ID: <4e8f45e7-298f-ac3d-4dd6-66dcadb1479a@evertpot.com>
Date: Tue, 26 Jan 2021 17:11:57 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <CAPBurBvUuQZigMCPHu3h5FhyNJDJauzZQdWbNR2R5yxWO9R_4w@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------00BA34B850CD300D08F71512"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/1K5snBC2ArdSKlNhssBPXyPjsWI>
Subject: Re: [httpapi] Link relationship types for authentication
X-BeenThere: httpapi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Building Blocks for HTTP APIs <httpapi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/httpapi>,
 <mailto:httpapi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/httpapi/>
List-Post: <mailto:httpapi@ietf.org>
List-Help: <mailto:httpapi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpapi>,
 <mailto:httpapi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2021 22:12:05 -0000

This is a multi-part message in MIME format.
--------------00BA34B850CD300D08F71512
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2021-01-26 4:24 p.m., Graham Cox wrote:
> Apologies if this has already been covered, but have you looked into 
> the overlap between this and OpenID Connect? I'm far from an expert, 
> but it seems that some - though not all - of the relations defined 
> here correspond well with the actions that OIDC offer, though 
> obviously they work in notably different ways. (The /authenticated-as/ 
> relation doesn't have any direct mapping in OIDC that I can think of, 
> but they others all map on to *something*)
I'm somewhat aware of the specifications and general plumbing. The link 
relations I'm hoping to register are extremely general though, and don't 
impose any sort of protocols or media types.

For example, a browser extension might find a a link with rel="logout", 
and render a logout button in a toolbar. It would be good to know if 
this is fundamentally incompatible with protocols like OpenID Connect, 
but I'm also not the person to say anything about this with confidence.

Evert

--------------00BA34B850CD300D08F71512
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 2021-01-26 4:24 p.m., Graham Cox
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPBurBvUuQZigMCPHu3h5FhyNJDJauzZQdWbNR2R5yxWO9R_4w@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>Apologies if this has already been covered, but have you
          looked into the overlap between this and OpenID Connect? I'm
          far from an expert, but it seems that some - though not all -
          of the relations defined here correspond well with the actions
          that OIDC offer, though obviously they work in notably
          different ways. (The <i>authenticated-as</i> relation doesn't
          have any direct mapping in OIDC that I can think of, but they
          others all map on to *something*)<br>
        </div>
      </div>
    </blockquote>
    I'm somewhat aware of the specifications and general plumbing. The
    link relations I'm hoping to register are extremely general though,
    and don't impose any sort of protocols or media types.<br>
    <br>
    For example, a browser extension might find a a link with
    rel="logout", and render a logout button in a toolbar. It would be
    good to know if this is fundamentally incompatible with protocols
    like OpenID Connect, but I'm also not the person to say anything
    about this with confidence.<br>
    <br>
    Evert<br>
  </body>
</html>

--------------00BA34B850CD300D08F71512--

