To clarify on JSON-LD - I'm not suggesting we should support it as a
*format*; just a bit concerned that we're restricting client metadata
response content-type to "application/json", which might be different in
the reality. Would it make sense to allow "application/json" as well as its
subclasses ("application/*+json")?Dmitry On Wed, Dec 14, 2022 at 10:57 PM Tobias Looker <tobias.looker= 40mattr.glo...@dmarc.ietf.org> wrote: > > I see the value of client discovery for registered clients as well as > for registering clients. For example, the client may be registered at a > number of ASes, and a discovery document lets the client update its > information once at its discovery endpoint rather than having to > manually update the information at each AS. > > Can you elaborate more on what you mean by "for registered clients as > well as for registering clients". IMO this is where the language around > client registration in OAuth2 starts to break down. For example if a > clients first interaction with an AS is via an authz request using a > client_id that is a URL, and that AS is able to resolve the clients > metadata in real time and elects to proceed with the request based on that > information alone, would you consider that client registration has taken > place? Because I would not, an AS in this model may choose to capture some > state about the client or transaction (e.g that a transaction has taken > place with that client) but that doesn't constitute registration IMO. > > > A key example of this (pun intended) is client key rotation. => I'd > suggest updating the introduction to not be focussed on registration, but > as a way for the AS to learn about a client. > > Agreed, what part of the introduction do you feel doesn't communicate > that? Really most of the introduction is about trying to distance somewhat > from the concept of "client registration" as I don't believe that is > actually what is occurring in a client discovery style model. > > > 2. I'm strongly opposed to JSON-LD as an optional format. Extra > complexity for an AS to support with no added value since JSON is already > being supported so would not be able to take advantage of any JSON-LD > features. > > I somewhat agree with this, I don't see the value of making the metadata > document JSON-LD compatible either, but given the metadata document itself > is JSON and is extensible, I dont see a problem with implementations > wishing to include JSON-LD processing directives (e.g @context) in their > metadata if they wish? > > > This proposal presumes the client provides the same redirect_urs to > each AS. In the clients that I have deployed, I have unique redirect URIs > for each AS to assist in knowing which AS has sent back the redirect. For > example, I append an AS specific slug to the redirect URI. How would that > be handled in this proposal? One path would be for me to provide an AS > specific URI for the client to each AS. > > This is a good call out and something I intend to elaborate on further, > beyond just different redirect_uris I think there are instances where a > client may have slightly different metadata based upon the AS it is > interacting with and the way this can be supported is via unique client > ID's e.g > > Client ID for AS1 => https://client.example.com/as1 > Client ID for AS2 => https://client.example.com/as2 > > Which I believe is what you were suggesting? So in short, the draft does > not presume the client has the same redirect_uris for each AS, because the > client could have multiple client IDs. > > > I did not see URIs for the standard terms (ToS) of service and privacy > policy (PP) URIs > > Currently the draft is not aiming to define new metadata elements instead > it refers to RFC 7591 and there you will find permitted registered elements > like tos_uri and policy_uri which I believe serves the purpose you are > referring to? > > > I prefer the other proposal I saw where 'client_uri` was used to signal > that client info was at a URI rather than using 'client_id', and client_id > and client_uri would be mutually exclusive. Doing this for both the > authorization and token endpoints would be what I would propose. Note that > we are deprecating the redirect_uri to be in the token request in OAuth 2.1. > > Just to clarify which proposal are you talking about? This is the current > editors draft of Client discovery ( > https://mattrglobal.github.io/draft-looker-oauth-client-discovery/draft-looker-oauth-client-discovery.html), > the subject of this email thread? R.e your comment about making client_id > and client_uri mutually exclusive I agree, that is the direction taken with > client discovery. What I'm sure is probably already obvious, we can't omit > the client_id from OAuth2 requests so the question is if this isn't where > the client describes itself with a URL, where does it? And what do you put > in the client_id for the request instead? > > > With client discovery, we can more easily move to the client > authenticating with a signed request rather than a client secret, so a > jwks_uri would be a great addition > > Agree, but just to clarify RFC 7591 already defines a metadata element for > JWKS URI, so the question is, what does the client discovery I-D need to > define this method of client authentication fully? > > > 10. The string comparison in section (6) is confusing. My understanding > is that we have gone with byte comparisons with no transformations. What am > I missing? > > This language was lifted directly from RFC 8414 ( > https://www.rfc-editor.org/rfc/rfc8414#section-4) it is primarily there > to ensure complete definition around how an implementation should check the > client_uri value returned in the resolved JSON metadata document matches > the client_id/client_uri used to perform the resolution. This check is > conceptually the same to what we require implementations to do when > performing authorization server (openid provider) discovery in checking the > issuer field. > > Thanks, > > [image: Mattr website] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> > > > > *Tobias Looker* > > MATTR > CTO > > +64 (0) 27 378 0461 > tobias.looker@mattr.global > > [image: Mattr website] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> > > [image: Mattr on LinkedIn] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0> > > [image: Mattr on Twitter] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0> > > [image: Mattr on Github] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0> > > > This communication, including any attachments, is confidential. If you are > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > ------------------------------ > *From:* Dick Hardt <dick.ha...@gmail.com> > *Sent:* 15 December 2022 09:03 > *To:* Dmitry Telegin <dmit...@backbase.com> > *Cc:* Tobias Looker <tobias.looker@mattr.global>; oauth@ietf.org < > oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] OAuth2 Client Discovery > > EXTERNAL EMAIL: This email originated outside of our organisation. Do not > click links or open attachments unless you recognise the sender and know > the content is safe. > > > 1. I see the value of client discovery for registered clients as well as > for registering clients. For example, the client may be registered at a > number of ASes, and a discovery document lets the client update its > information once at its discovery endpoint rather than having to > manually update the information at each AS. A key example of this (pun > intended) is client key rotation. => I'd suggest updating the introduction > to not be focussed on registration, but as a way for the AS to learn about > a client. > > 2. I'm strongly opposed to JSON-LD as an optional format. Extra complexity > for an AS to support with no added value since JSON is already being > supported so would not be able to take advantage of any JSON-LD features. > > 3. I agree with using .well-known for discovery. It has become pretty > common now, and that pattern helps prevent there being a conflict with any > existing content / routes that are at the client endpoint. > > 4. This proposal presumes the client provides the same redirect_urs to > each AS. In the clients that I have deployed, I have unique redirect URIs > for each AS to assist in knowing which AS has sent back the redirect. For > example, I append an AS specific slug to the redirect URI. How would that > be handled in this proposal? One path would be for me to provide an AS > specific URI for the client to each AS. > > 5. In HellÅ -- we offer developers the option to include a logo to be used > for dark themed experiences in addition to the standard light themed > experience. > > 6. I did not see URIs for the standard terms (ToS) of service and privacy > policy (PP) URIs > > 7. on the ToS and PP topics, we could include version info so that it is > easier for the AS to detect if the ToS and PP have been updated since the > last time the user provided consent > > 8. I prefer the other proposal I saw where 'client_uri` was used to signal > that client info was at a URI rather than using 'client_id', and client_id > and client_uri would be mutually exclusive. Doing this for both the > authorization and token endpoints would be what I would propose. Note that > we are deprecating the redirect_uri to be in the token request in OAuth 2.1. > > 9. With client discovery, we can more easily move to the client > authenticating with a signed request rather than a client secret, so a > jwks_uri would be a great addition > > 10. The string comparison in section (6) is confusing. My understanding is > that we have gone with byte comparisons with no transformations. What am I > missing? > > /Dick > > 10. > > > > On Wed, Dec 14, 2022 at 5:14 AM Dmitry Telegin <dmitryt= > 40backbase....@dmarc.ietf.org> wrote: > > Hi Tobias, > > On Wed, Dec 14, 2022 at 2:49 AM Tobias Looker <tobias.looker= > 40mattr.glo...@dmarc.ietf.org> wrote: > > > There are certainly things we could explore here, one such option could be > to continue to only return application/json but for the document to include > an element like "@context" in the response if its desired that the metadata > be processable as a JSON-LD document. > > > I'd generally agree; my only concern about the Content-type is that it > could be set by the web server rather than the developer, and developers > might have no control over the web server configuration. If, for example, > the metadata is deployed as a static JSON-LD file, and the web server uses > MIME DB, then it will serve the resource as application/ld+json rather than > application/json (unless reconfigured to do so). > > > > Yes I've had similar thoughts about this, I think RFC 9111 could be a good > basis. What remains a little unclear to me is what normative requirements > we might impose on implementers in regards to caching, for instance I think > requiring clients hosting their metadata to implement HTT request caching > would be too strict, but if they are to implement it, RFC 9111 is > recommended and if you do here is how it must be implemented? > > > I agree that requiring clients to implement caching (i.e. to guarantee Age > and Cache-Control headers) might be excessively strict. But in the case > where the headers are not present, I think we should recommend the ASes to > implement some opinionated defaults (e.g., default TTL for client metadata > = 1 hour etc.) > > Dmitry > > > > Thanks, > > [image: Mattr website] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> > > > > *Tobias Looker* > > MATTR > CTO > > +64 (0) 27 378 0461 > tobias.looker@mattr.global > > [image: Mattr website] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> > > [image: Mattr on LinkedIn] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0> > > [image: Mattr on Twitter] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0> > > [image: Mattr on Github] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0> > > > This communication, including any attachments, is confidential. If you are > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > ------------------------------ > *From:* Dmitry Telegin <dmitryt=40backbase....@dmarc.ietf.org> > *Sent:* 14 December 2022 06:30 > *To:* Tobias Looker <tobias.looker@mattr.global> > *Cc:* Ben Schwartz <bem...@google.com>; oauth@ietf.org <oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] OAuth2 Client Discovery > > EXTERNAL EMAIL: This email originated outside of our organisation. Do not > click links or open attachments unless you recognise the sender and know > the content is safe. > > Hello Tobias, thanks for the draft! In regards to prior art, I'd like to > mention Solid Project and their OIDC flavor, Solid-OIDC: > https://solid.github.io/solid-oidc/#clientids-document > > They're using a similar approach (and have been for years), though with > some differences: > - client_id points to a URL that must resolve to the client metadata > document directly (no .well-known/* used); > - the document's format is JSON-LD, a superset of JSON. > > In order to maintain compatibility with Solid and similar existing > technologies, would it make sense to mention that: > - while retrieving client metadata, AS should recognize not only > application/json, but application/ld+json (or maybe even > application/*+json, as per > https://datatracker.ietf.org/doc/html/rfc6839#section-3-1)? > - any unknown fields (like JSON-LD "@context") must be ignored? > > On an unrelated note, it would be nice to cover the issue of caching the > client metadata on the AS side. Obviously, we wouldn't want to re-request > the metadata upon every request to the authorization endpoint. Would RFC > 9111 suffice here? If so, which subset should be guaranteed to be supported > by the AS? > > Thanks, > Dmitry > > On Wed, Nov 9, 2022 at 8:36 PM Tobias Looker <tobias.looker= > 40mattr.glo...@dmarc.ietf.org> wrote: > > Hi Ben, > > See below for some thoughts. > > > I'm having trouble understanding the precise URL structures that are > used here. Can client_uri include a nontrivial path? Why is it necessary > to repeat client_uri in the response JSON? > > The intent here is to follow how "OAuth 2.0 authorization metadata" works > (RFC 8414) which requires the client resolving the authorization server > metadata to check that the issuer in the resolved document matches the > issuer URL they started the resolution with, see below for the relevant > extract from RFC 8414. > > " > > The "issuer" value returned MUST be identical to the authorization > server's issuer identifier value into which the well-known URI string > was inserted to create the URL used to retrieve the metadata. If > these values are not identical, the data contained in the response > MUST NOT be used. > > > " > > So the equivalent with our draft is to require the authorization server to > validate that the client_uri returned in the clients metadata response > matches the URL that was used to retrieve the metadata. > > > The use of .well-known is a bit unusual. Why not just host the JSON at > the client_uri? > > Just to clarify it is, just under a well-known path? e.g if the client uri > is https://client.example.com then the metadata would be published at > https://client.example.com/.well-known/oauth-client > > > Finally, I note that the section on Impersonation Attacks doesn't > mention the client_name or logo_uri. If these are to be shown to the user, > they present a very serious impersonation risk that ought to be discussed. > (The client_name also might need to be localized, which could be done by > fetching the JSON document with an appropriate Accept-Language request > header.) > > Yes absolutely agree this is an important security consideration to > highlight, I will capture an issue. > > > Thanks, > > [image: Mattr website] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> > > > > *Tobias Looker* > > MATTR > CTO > > +64 (0) 27 378 0461 > tobias.looker@mattr.global > > [image: Mattr website] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> > > [image: Mattr on LinkedIn] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0> > > [image: Mattr on Twitter] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0> > > [image: Mattr on Github] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0> > > > This communication, including any attachments, is confidential. If you are > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > ------------------------------ > *From:* Ben Schwartz <bemasc=40google....@dmarc.ietf.org> > *Sent:* 10 November 2022 07:04 > *To:* Tobias Looker <tobias.looker@mattr.global> > *Cc:* oauth@ietf.org <oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] OAuth2 Client Discovery > > EXTERNAL EMAIL: This email originated outside of our organisation. Do not > click links or open attachments unless you recognise the sender and know > the content is safe. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
