Responses inline ... On Wed, Dec 14, 2022 at 2:57 PM Tobias Looker <tobias.looker@mattr.global> 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. > Thanks for asking for clarification, I had not caught the distinction that a client that was unregistered would not be registered using this flow. Registered client => a client where the developer has gone to the AS and registered their client, or has gone through dynamic client registration Change my roding to be discovery for registered and unregistered clients. At Hellō -- all clients must be registered => I would like to enable the clients to update their config by updating their discovery docs rather than having to login and edit through a console. > > > 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. > "Instead of requiring a registration process, this specification describes a model where a client identifies itself to the authorization server with its client_uri, which can be resolved to its metadata in a similar way to how an authorization server makes its metadata available to a client via [RFC8414]." We will still require registration. > > > 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? > I've found the Verifiable Credential spec supporting both JSON and JSON-LD to be a HUGE confusion point for implementers. Pick one or the other. I pick JSON. > > > 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. > This is what I was thinking. I would add to the draft wording to describe it as a practice so people understand it is possible. > > > 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 did not see them in the non-normative text => people don't think they exist. Related to this, which metadata elements are optional and which are required? Does each AS decide? > > > 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? > I don't recall the proposal, and it doesn't really matter where it came from for our discussion. Sorry. Why can't we omit client_id from OAuth2 requests? That is what I am suggesting. The client sends client_uri instead. If the AS does not understand client_uri, then it does not know how to do client discovery and will fail. If it does, then it knows what to do. I think keeping client_id in the request when discovery is required will be problematic as AS that do not understand it will not know why it can't find the client_id in its DB and provide an unuseful error response. I might have missed it -- is there a proposed entry for AS metadata value that declares the AS supports client discovery? > > > 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? > Need to define that jwks_uri can be part of the metadata, and have it in an example. > > > 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. > Ah - got it. All good. > > 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
