# OAuth WG Agenda @ Yokohama {#oauth-wg-agenda--yokohama} Tuesday March 28, 2023 ## Chairs update – Rifaat/Hannes (10 min) {#chairs-update--rifaathannes-10-min} https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-chairs-update-01 two meetings this week -- today and friday side meetings: none this time Roman: it's inappropriate to hold effectively working group meetings during side-meeting time * we recognize that we want to make maximum productivity * iesg says: we don't do official meetings in the side meeting slot * ietf suggests to schedule more interims, instead. ### WG Updates {#wg-updates} RFC updates: RAR and JWT for token introspection Pub requested: DPoP & step-up authn waiting for shepherdπŸ‘: security BCP Daniel: we have a couple editorial things * we checked alignment with oauth 2.1 w/aaron * all things are not new to the wg but need to be aligned * CORS text to be added * done "soon", goal 2-3 weeks after IETF ## SD-JWT – Kristina/Daniel – (20 min) {#sd-jwt--kristinadaniel--20-min} https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-sessb-sd-jwt Daniel: please read the SD-JWT draft. ### 'simple' is a feature {#simple-is-a-feature} simple standard to provide selective disclosure; shortest path, using standard crypto (salted hash-based) We hope the current verison looks like this. sd-jwt in five steps: 1. prepare user data 2. create disclosures * JSON array consisting of 3 elements, salt, claim name, claim value. 3. hash claims and put the values there instead of original claims 4. take the original with the replaced claims and sign over it (standard JWS) 5. transform disclosures into base64 and use tilde (~) to put it all together What do we do with that? The issuer produces the sd-jwt and disclosures, and transfers this stuff to the holder of the credential. The holder or end user then presents the credential, and some disclosures to a verifier, only the ones needed by the verifier If desired the holder can provide a bind JWT, to the verifier as well, which is based on a key commited to the credential by the original issuer. The verifier checks the signarure of the SD-JWT, confirming it comes from the issuer. The verfier then hashes the disclosures and discovers if they are present in the original credential. This means any generic implementation must implement the hash. The verifier also checks the holder binding if present. ### changes since last version {#changes-since-last-version} We have had format changes since the last IETF meeting. We now allow **nested disclosures**, this supports nested objects, which is very natural. This change enables sd-jwts with fine granularity, and makes the algorithms easier to implement. We also added an example that features JSON-LD to support the W3C Verifiable Credential use case. We also added privacy considerations for holder binding and other details. ### Discussion points for -04 {#discussion-points-for--04} Kristina: The point of the JSON-LD example, shows that any JSON can be used as the payload, and JSON-LD is just one example. We will cover 3 discussion points: * media types * selective disclosure of array elements * do we support JSON serialization #### Media types {#media-types} SD-JWT is not JWS. The processing rules are different, even if some libraries can be reused. We need to be able to distinguish between types. What about application/jwt use case? can we signal that it is an sd-jwt? JWT BCP recommends specific types (typ) potentially a media types for the payload as well (cty) Also consideration of JWE wrapper on SD-JWT, cty would be useful for this use case. also, considering full disclosure (issuance) or selective disclosure (presentation) Should we reserve the structured suffix for sd-jwt ? There is a PR that attempts to clarify structure, please review. Orie: in favor of specific typing and reserving structured suffix * iana already contains a lot of +jwt examples, need to distinguish Mike: it would be logical to use application/sd+jwt for (typ) Orie: clarifying, you want sd+jwt not sd-jwt? Mike: yes Mike P: esp. after having sat through mediaman, structured suffix could be problematic * talk to mediaman Krstina: I have opinions, lets discsuss later. #### Disclosure of Array Elements {#disclosure-of-array-elements} Consider dislosuing a single element of an array. We think its possible, we have a proposal, but do we need it? Do you have a use case or need in the market, for disclosing array elements? First propsoal: Receiver of an sd-jwt will need to distinnguish array of hashes from plain text... so we need to signal that difference. We could use prefixing / namespacing to suppport this. Torsten: We have experimented with education credentials and sd-jwt, so we have use cases for achievements that use arrays, we really appreciate the work on arrays. Gulan Wang: How does the disclosure scheme work? Daniel: it's simple; hash the plaintext, sign over the hash * add a nonce before hashing * salted hashes have been used by other schemes Gulan Wang: What about group signatures? They are more complex. Kristina: you can use whatever JWS signatures support Tobias: For the array elements, what datatypes would be supported in the arrays? numbers, strings, objects? Daniel: the disclosure will work the same way, but the hash takes the place of the value. Tobias: Unless you consistently validate all the array elements, there might be issues. * A single directive makes sense * Perhapse a map would be better to signal than an array. Daniel: There are trade offs. #### JSON Serialization {#json-serialization} Kristina: Jades from europe could use a JSON serailization. Daniel has a proposal, where payload an disclosures are seperate members. Another approach would be to use base64url encoding. The first appraoch is cleaner, and uses less encoding. But the second one uses the same processing rules. ### Summary {#summary} We have several implementations. We may split the python code to a seperate repo. 2 new implementations on in typescript and one in java. The new java implementation by Taka from Authlete has an excellent readme ## Browser-based Apps – Aaron (20 min) {#browser-based-apps--aaron-20-min} https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-sessb-oauth-21-and-browser-apps-bcp ### Update on OAuth for Browser based Apps {#update-on-oauth-for-browser-based-apps} Aaron: best practice for oauth apps running in browser (typically JS) * may or may not have backend component complimentary version of "native apps" spec There is a new section on storing tokens in the browser, such as using local storage, keeping the tokens away from the browser using a backend component. "why not to use cookies to store tokens" Reference to sender constrained tokens and DPoP There is a new section that is about aquiring tokens instead of building an app. Lots of editorial updates. A note about implicit flow, and support for CORs Lots of discussion about service worker pattern. We have described the limitations of service workers for managing OAuth flows. ### Issues {#issues} new pattern: BFF store access tokens, but store them as http-only cookies * no persistent storage in the backend itself storage isolation: TLDR there is no best way to store tokens in browsers, XSS attacks are a thing, so using a backend just moves the problem elsewhere... service worker is a decent option, but then there is no persistent API, and indexdb is shared. should we document the gap in browser tech, where we wish there was a better solution should we ask for a better api to store tokens? Torsten: i think you have your best practice already in mind, "just use the backend" * is "call for action" something to put into BCP? I wouldn't * in 3 years it might read weird, maybe reach out instead Aaron: should we identify Orie: this is a gap that we feel a lot as webapp developers; 100% the WG should reach out and engage other communities * should say something stronger Mike j: is browser storage landscape part of what's changing? does it differ? Aaron: afaik, no pending changes, relatively consistent Kristina: The W3C FedCM is working on putting browser in flows, and perhaps already has ideas about storing tokens Aaron: would be great to reach out David: some browser sandboxes are more strict for isolation it would be a very big ask. Tobias: this would be a good ask of the community, what woul dbe the properties of a secure storage? * ie if it's available to JS you still have XSS, but could prevent some kinds of theft Should we gather deeper requirements before asking? Aaron: it would be nice if the service worker had a permanent storage location that was isolated to the service worker. This would address token theft, but not token use, as it says in the draft. The other option would be DpoP with a hardware backed key, which would require coordination with OS vendors. That is a much bigger project. Not posible to capture as a BCP, since it requires future work. The edge is going up to but not covering hardware backed keys. ## OAuth 2.1 – Aaron (20 min) {#oauth-21--aaron-20-min} https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-sessb-oauth-21-and-browser-apps-bcp Aaron: Client ID definition, is now meant to allow for clients to bring their own ID. The text around verifying the identity of the resource owner.... its also been awkard, and now it refers to authenticating the user. Changes in the context of the security BCP have been back ported. Lots of editorial. The grant types are now main sections, and they define parameters, and they all extend from the core token type. scope parameter is defined by specific grant types. ### Remaining work: {#remaining-work} * Security BCP alignment * remove normative language from security considerations * double check 2.0 Aaron: explicit resource owner authentiation, the idea is if a client is not authenticated, there is text that says the AS SHOULD involve the resource owner... vittorio asked if they means prompt for credentials... what does "involve" mean? Does this apply to public or confidential clients? Justin: This is really tricky to specify, because there are a lot of systems today, where there is no strong auth event, and there is instead a "risk endgine", i beleive this text comes from OAuth 1 world, where is was expected to be a full user authetnication (logout and login) Stating this is requirments langauge is difficult. We know the resource owner is there, and what do we want to avoid: * quite login with prompt = none... We want to avoid the case of an attacker quietly creating a session on someones behalf. Torsten: I think I wrote that text, the intention was to add another check in cases where you cannot auth the client. it was intended for public clients, and to get a confirmation from the user, i think it is inline with existing methods and OAuth 2 philosophy. Another check for public clients to prevent impersonation. George: piling on, consent is what I have seen used for this scenario. Aaron: The question is do you want to re-auth the user? or... We should make it clear we don't need to ask for a password again, but confirm the AS is still happy with their session. Vittorio: It sounds like we want to provice extra opportunity to the user, but the user is easy to fool... I don't think we can do much more... perhapse we should use the word consent instead.... Aaron: sounds like we should ask the user for consent. #### Repeated Authorization Requests {#repeated-authorization-requests} Aaron: similar to the last issue... The prompt = none flow / another authorization request. Maybe the SHOULD is fine in security considerations, maybe we don't need more clarity here. Torsten: It is in client impersonation section, it is meant to improve security in public clients. Aaron: public clients still might want prompt none, silent flow Torsten: But thats a contradiction, we don't know who you are talking to. Vittorio: using the iframe is completely mainstream; "should" covers us, but a lot of people look at our specs as guidance * language there is fine as long as there's extra context We should clairfy common practice for access tokens without bugging the user. Mike Jones: this is common practice and it serves to support user experience. Regardng torsten's comment, you are talking to the same party on the channel you were already talking too. Aaron: but that is the issue, the silent refresh gives the attacker the token, even if the burden for the attacker is high. Torsten: you don't know if the party asking for a refresh token is the original party. We should spell out that the attacker may get a token. Mike Jones: you are already processing content on this channel. Aaron: one example is dns poisoning; silent refresh could point to something else vittorio: couldn't you just use the url to ask for a new token anyway? good to call out, but just saying 'should not' scares people too much Torsten: There is a combination of mesaures that must be in place, the redirect and uri checking, leaking of codes should be prevented to outside parties, if we connect those 2 pieces I would be fine. Filip Skokan: Adding on to what Torsten agreed to, some context would be good, beyond redirect uri, we should do what we do today to make sure we respond to the same party, is validating the origin that we post message the response to... we already do this. #### Differences between Mobile and Desktop Apps {#differences-between-mobile-and-desktop-apps} Aaron: native apps BCP, most of it applies to mobile phone OS, and not desktop apps. Many desktop apps do not follow mobile app guidance. The way to capture the current state is leaving the desktop world more open... and take native apps recommendation and make sure it refers to mobile os. vittorio: good rec, but we can do better. Some things work in mobile based on isloation Lets not blindly ask people do to the same things we do on mobile, because the benefits are not there and the experience is not good. #### Unidentified Clients {#unidentified-clients} Aaron: See the section on grant types, client id is in there but we should make it optional. each grant type will say whther or not it's required #### Next Steps {#next-steps} * Browser BCP WGLC * Security BCP IESG * OAuth 2.1 WGLC ## Client/Trust Management – Kristina/Torsten (20 min) {#clienttrust-management--kristinatorsten-20-min} https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-clienttrust-management-00 Torsten: Kristina, Tobias and I are presenting an extension for robost mechanisms for client metadata. To give context, we are working on a set of protocols called open id for verifiable credentials. The fundamental problem which we discussed at IETF 115. There are lots of parties, issuers and verifiers. Normally this would mean a wallet would need to register with lots of issuers and verifiers would need to register with lots of wallets. An AS should be able to use external client ids (outside party id)... not necessarily trusted. client id and client metadata can be externally managed, but... there is not just one way to go this. We wrote a list of mechanisms we have discovered in the wild, inclusing dynamic client registration, x509, DIDs, TRAIN, etc.. We have seen ecosystems use a mechanism, such as in open banking dynamic client registration. There are also proprietary mechanisms. A wallet miht need to be connected to multiple ecosystems, for example EU EIDAs might need x509, but the wallet might need to connect to multiple ecosystems. The wallet should be able to determine from the request context, what mechanism would be used. The mechanism impacts in the request must / should / must not be signed. For example there is trust chain in OIDC for passing additional data. This could be complex to implement, we decided ot add a new request parameter. to dinclude to the AS which mehtod a client wants to use. we call it a client id scheme, it determins the behavior of the wallet, and additional parameters, including conveying client meta data that might be attested or self asserted. Some of this is built into OIDC for Verifiable Presentations. List of mechanisms: * pre-registered (backword compat) * redirect\_uri (client id / introduced in siop v1) * entity\_id * did (signals that the client uses a DID) Still considering: * x509 * train Kristina: VC requires profiles; ISO provides one profile for mdocs, including x509 mechanism (very specific to ISO) not ment to be exclusive list here, meant to have extension points Torsten: on the left, authorization request using redirect\_uri and client\_id as the same value, with additional self asserted client meta data. on the right, you see a request that uses OIDC federation, using entity\_id using well known location and api endpoints to validate a trust chain, andy redirect\_uri is allowed as long as it comes from the apis These changes have simplified the specificaiton text. Tobias: client\_ids that are not managed or signed by the AS, we want to support wallets and credential exchange, but are there more use cases we should be aware of, is this generally useful for OA vittorio : i have a hard time following when you're using terminology that isn't strictly oauth; would be clear if we use oauth primitives in the past, some customers interpreted structure of client id is a problem, like AS depending on internal schema things break when AS changes its internal schema There are risks generalizing structured client ids, there is some risk that this may impact future clients. Torsten: The wallet in this use case acts as an AS. The client id may not have structure, it is up to the method. We have already crossed the point where the AS manages client ids, we have gone further to indicate how the outside party is managing these identifiers. Pieter: Interesting in the context of workload identity, its nice to now have the AS manage these identifiers... Evan you might want to say something. Aaron: I agree with most of what you have, but in which situations are paramters required? How do we know when a parameter is needed, and how to we ensure people don't end up with stuff they don't actually need. Tobias: we don't want to encourage people to sniff the client id Kristina: the multihoming nature of the wallet, is emerging as a pattern, in some cases we may need to use DIDs, in others we must use x509... and it can lead to sniffing... and it is not great. ## PoP Security Architecture – Nat (15 min) {#pop-security-architecture--nat-15-min} https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-architecture Nat: PoP architecture document * describes Proof of Posesssion architecture for OAuth started back in 2014. pretty well-written assumed it was completed, but author of an academic paper couldn't find the draft The draft is not present in OAuth becuase it was marked dead. was almost ready -- passed IESG review still believe it has useful information; we talk about sender-constrained a lot these days do we have an appetite to have it cross the goal line? (so it can be referenced) Hannes: Back then, we worked on a lot of documents, and this was the overview document. it looked like the authors lost interest and steam on it... it will require updates. Justin: I forgot I co-authored this. At the time, we had plans to move OAuth2 to move beyond proof of posesssion and the there were lots of other ideas (HTTP Signatures) I think it makes sense to relate these concepts. Perhapse we can references mTLS and DPoP drafts. Roman: I heard procedural... this went to IETF last call... this basically would be a new document, if we pick it up. Richard: My impression is that proof of posession is the future of this community, we are headed towards a world where this is important, and it makes sense to revive the draft. Joseph S: I think this would be useful, it needs updates, I would be happy to review. Kristina: Where would this draft be referenced from? I would Hneed time to review. * asking for more time and more context Torsten: lets first learn more of the context. Nat: only within IETF, but a lot of people seem to be talking about sender0constrained or key-constrained things, with different vocabulary * having something to point them to to be used generally would be good Torsten: struggling to understand how pop architecture fits into that picture given we have dpop and mtls * should this go in 2.1 or security BCP? * do we want to just get terminology straight nat: more than just terminology; list of potential threats with each type of thing Roman: we need to finish security BCP, lets not hold that up. ## OAuth & SPIFFE – Evan/Pieter (15 min) {#oauth--spiffe--evanpieter-15-min} https://spiffe.io/ Evan: I am presenting today with Pieter K. I'm new here. We have been discussing workload identity and OAuth. The goal today is to give context on SPIFFE, and use cases. 1. make it clear how they work together 2. see how/if they can converge SPIFFE is a set of specs SPIRE is the only standadalone one. SPIFFE solves the bottom turtle problem, workloads come and go all the time, and they need to be able to establish their idenitity. short lived documents and key rotation from the root all the way down. there is no authorization, we look towards it, by establishing a foundation and letting poeple bring their own framework. We like to define using profile son top of existing documents. 2 primary ones today are x509 and JWT. we provide trust bundles as well. SPIFFE have a lot of overlap with OAuth (but they aren't the same). SPIFFE to boostrap an OAuth client. SPIRE is when a workfload works with a server to provide remote attestion to establish an identity. ### Use case 1 Access workloads in another domain {#use-case-1-access-workloads-in-another-domain} how do we do workloads in different domains? choose your own adventure today, very undefined ### use case 2 no spiffe cllient registration {#use-case-2-no-spiffe-cllient-registration} registration in oauth, we have hosts where they have an identity already, how can we add workloads to this? SPIFFE keys rotate very quickly, so validators need to be aware of key rotations. ### Use case 3 preserve call stack identities {#use-case-3-preserve-call-stack-identities} This blends with user identity, and policy issues for example, a payment service which only wants to move money, if the owner of the account has issued the request, and the request has transited the fraud detection service. ### use case 4: token theft {#use-case-4-token-theft} SPIFFE required aud to be set, but it is not super strong. We are interested in token binding to the request. It is important for SPIFFE to avoid expensive network calls... because of perf and availability issues, we want local operations. ### use case 5: finer grained authorization {#use-case-5-finer-grained-authorization} not as sure how well this fits here As attestion processes occur, they emit useful signals. How can we consume this at policy decision point? useful for implementing ABAC. ### use case 6: inter-domain meta-data distribution#\# {#use-case-6-inter-domain-meta-data-distribution} SPIFFE has federation, but we support x509 and JWT. How to discover the JWKs endpoint? How do you authenticate the endpoint? Once that is exchanged everything is good, but it is hard to encapsulate. ### use case 7: monitoring and remediation {#use-case-7-monitoring-and-remediation} SPIRE is good. Use Case \* Have any use cases? ### Discussion {#discussion} Pieter: Next steps, we want to document connection points to OAuth... we want to show how OAuth can bridge to SPIFFE. Should we create a BCP? We are seeking feedback on this. Vittorio: Thanks, like your scenarios. Is there a layering mismatch? OAuth does not do identity but can be used to carry identity. I would expect SPIFFE side to say how they use OAuth, not the other way round. Evan: Not sure how to connect to OAuth because of key rotation; had engaged in MTLS discussion Joe s: would be useful to define, don't know exactly where Lots of use cases, maybe they don't all fit in this group. Evan: could be in our community, most important thing is input and collaboration # Friday, 31. MΓ€rz 2023 {#friday-31-mΓ€rz-2023} Note takers: Hannes Tschofenig, Joseph Heenan Roman will talk to the IESG about the extra side meeting time that was cancelled and how to resolve this problem in the future. ## JWT Embedded Tokens – Rifaat/Dick (15 min) {#jwt-embedded-tokens--rifaatdick-15-min} https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/ Rifaat: Purpose: audit trail, real time isplay of info, eval & auth Use case includes embedding tokens from other issuers, e.g. STIR diverted calls, id tokens from other parties to aggregate different claims Tokens to be embedded are sent to token endpoint in new endpoint, response with new token is returned directly or be value. Authors are asking for a call for adoption. Atul: What's an example with more than one token? Rifaat: Typical use cases are one token, but didn't want to rule out multiple. Guisseppe has one use case with multiple. Vittorio: Token exchange is misunderstood. Concerned we're doubling down. No guarantee AS at end of chain understands claims from other parties. OpenID Connect as claim aggregation. Nat: id\_token has facility to include other tokens. Mike: This is aggregated & distributed claims in OpenID Connect core. Rifaat: I will look into this. Aaron: Concerns if access tokens are being embedded into other tokens. Not familiar with STIR so not sure if that token has the properties of an access token or not. Atul: Is it okay to embed an access token into a different token for an audit trail? Rifaat: There are some concerns if it's a simple bearer token. Atul: Should check that sending party has authority to delegate token. Dave Robin: Alarms bells with sending access tokens to other tokens. Consider removing signature or have security considerations. Rifaat: Absolutely Hannes: Should bring this to the mail list and answer some of the questions. ## Cross Device Flow – Pieter (15 min) {#cross-device-flow--pieter-15-min} https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/ Pieter goes through his slides motivating the attack. Main changes to the draft: Distinguish protocol patterns. Added further examples and more exploits. Mitigation limitations added. Next steps: Work in secure ranging and proximity, OpenID for Verifiable Presentations over BLE Open issues in the Github directory. Trying to coin phrases for the different attacks. Formal analysis of the cross-device flow is ongoing at Stuttgart Yaron: It is great to see people from academia to do a formal analysis. I would also like to see people who analysis the usability. I would also like to see the case covered where multiple requests are sent and the user has to decide. It will typically make the wrong decision. Pieter: Do you have some contacts you could introduce to us? Yaron: I will see what I can do. ## Identity Chaining – Rifaat/Pieter (20 min) {#identity-chaining--rifaatpieter-20-min} Presents the results of discussions among a group of people, as a preparation for this meeting. Different protocol flows discussed to address the use cases. Utilizes token exchange as a building block. Vittorio: The problem is not the wire-presentation but rather what needs to go into the token. It is not just a token exchange. Scalability should also be considered. Some of the information you put into the token is actually an environment variable. Pieter: yes, definitely issues around latency / round trips with microservices etc Hannes: Many of problems have been around for 20 years, lessons can be learn from prior attempts to solve. Would call it a semantic mismatch. ## Native Apps UX – Aaron/Pieter (20 min) {#native-apps-ux--aaronpieter-20-min} Work by Aaron, Pieter and George. Aaron presenting. OAuth for Native Mobile Apps. Not considering desktop for now. Current solutions are great for third party for security etc. Not good for first-party apps. Apps authors are unhappy with forcing users through browser. People are finding solutions to avoid RFC8252 (see slides) but create new problems. Hope is to come up with a first-party solution that uses native components. Rohan: Doing this work and standardizing it is important. This is just a pain for us (Wire). \[Rohan explains his scenario.\] Joseph: Definitely should work on this and clearly define what a first-party app is. Also look at app-to-app communication. Vittorio: We already have this today. You leave the biggest part undefined. We leave all the interaction with the AS undefined (as Microsoft does). I would like to see proposals to evaluate them since the devil is in the details. FIDO might be a better place to do this work. Aaron: We do have a couple of drafts and I didn't want to burden this discussion with this. (Those define the wire protocols) Justin: Vittorio's point needs to be seriously considered. There is merit in defining the protocol but it worries me that we will see proposals for sending passwords around. Rohan: We used HTML forms but we want the semantics defined. Justin: That's the reality of HTML. I don't know what we should do. ## Protected Resource Metadata – Mike (15 min) {#protected-resource-metadata--mike-15-min} https://datatracker.ietf.org/doc/html/draft-jones-oauth-resource-metadata There is some overlap with the next item. Both drafts enable RSs to identify ASs for a client to use. Resurrected old draft from 2016. John: In early days we indicated what AS is required by the RS along with scopes. This, however, raised concerns with security. This would be useful but we have to put in thoughts about security implications. Nat: Some of you may remember the OAuth Meta Draft (https://datatracker.ietf.org/doc/html/draft-sakimura-oauth-meta) from 2012, which was developed till 2017. The push-back was bearer token use but now we have phishing-resistent credentials and it might be useful to bring it back. Joseph: Agree with John, though this needs to go further than just security considerations. We need to make sure the flow breaks if user is sent to an authorisation server that doesn't know about this resource server, even if they don't know about this new proposed draft. Justin: This is a great idea that has sharp edges. This is deployed in UMA-based systems for a long time. GNAP does have a similar feature. There are some pretty big security considerations. There are well-documented attacks where fake discovery documents are used. There is also a huge privacy consideration here. We are going to a more distributed system and there are a lot of sharp edges. I don't think it is a bad idea but it is a dangerous tool. ## Authorization Server Discovery – Aaron/Ben (20 min) {#authorization-server-discovery--aaronben-20-min} https://datatracker.ietf.org/doc/draft-parecki-oauth-authorization-server-discovery/ Aaron wanted to continue the presentation on the next draft. He provides a number of examples (calendar apps, email apps) where RSs and ASs have no prior relationships. Not all use cases need this. The user brings/creates this relationship. Aaron believes that the non-phishable credentials are ready for deployment now. Aaron suggests to adopt draft-jones-oauth-resource-metadata. Justin: I love this space, which is why I worked on the dynamic client registration spec. It is still a difficult space and I would be in favor of combing both approaches because there are use cases where one or the other solution does not fit. Kristina: In the OpenID for Verifiable Presentations spec uses an alternative approach (see spec) Joseph: You indicate that this is a user-driven flow. Putting this responsibility into the user is difficult. Using the resource indicator is good. Aaron: The user is already responsible today to configure a mail client. We are starting with this assumption. Joseph: Agree with this but in other places we go a long way to avoid putting responsibilities to the users. Aaron: The problem scope is that we are in that world already. Tobias: The .well-known approach is probably more inline with today's OAuth approaches. I see use in both mechanisms as well. Aaron: There is also a relationship with the step-up authentication draft. Vittorio: For step-up authentication draft we explicitly rejected the functionality of discovery. For the overlap we should talk. Mike: Should we try to produce the combined draft? That seems to be the way forward. ## Power of Attorney (PoA) Grant Type – Olov (15 min) {#power-of-attorney-poa-grant-type--olov-15-min} https://datatracker.ietf.org/doc/draft-vattaparambil-oauth-poa-grant-type/ Sreelakshmi starts the presentation. Nat: OAuth uses a three party model. In OpenID Connect we have a 4 party model with CIBA. CIBA = https://openid.net/2021/09/01/openid-connect-client-initiated-backchannel-authentication-ciba-core-is-now-a-final-specification/ Rifaat: Did you post a mail to the OAuth list? Sreelakshmi: No, I haven't. Olov: We have collected all the comments from the London meeting. We also do multi-level delegation by doing PoA inside PoA. ## Misc {#misc} Aaron: I wonder whether we could do the interim meetings again. I thought that those were very productive. Rifaat: Send us topics.