> Am 07.11.2025 um 09:49 schrieb Warren Parad <[email protected]>: > > I think we have to assume some well meaning efforts on everyone's part. If > assume incompetence everywhere, no matter what solutions are recommended, > someone will find a way to avoid doing the secure thing. > > For instance, let's exclude unsecured nginx instances. Just like we should > exclude applications that don't use TLS. > I agree.
> For auth codes, it sounds like we should just reduce the recommendation down > to 60 seconds instead of 10 minutes. I agree. > But since these codes can't be reused, I'm really not sure how much impact > that has. Yes, but the attack vector here is that the attacker tricks the legitimate user’s client into not using the one-time auth code. That’s why it remains valid and the attacker can use it afterwards. > I completely reject the notion that "reverse proxies are out of control for > the developer". Everyone has their own considerations, if you can't trust the > team/company/tool managing your reverse proxy, that's not something that the > protocol needs to be concerned with. I refuse to believe "application logs > can be secured by developers" but somehow we should be concerned about what > happens on the proxy. I agree for SaaS deployments where client developers most probably have full access to the entire backend infrastructure, including reverse proxies, middlewares, … However, if administrators deploy any software (Nextcloud, Microsoft Exchange, …) on-premise, they most probably assume that they can deploy the software as any other web-based service, by putting a reverse proxy in front, adding middlewares like an external WAF, etc. They will most probably not assume, that secrets (the authorization code) will then get logged (reverse proxy) or sent to an external (the WAF provider) because they are provided as query parameters, because this is a very bad practice. Administrators will just not expect that and this opens up the potential for vulnerabilites. > Real time SIEM logs, there are lots of opportunities to sanitize the logs by > the infrastructure before getting to the SIEM. I don't understand why it > would make sense to completely change the recommendation for everyone, based > on the issues with one infrastructure setup. If fragments work better for > that application, I don't see the issue with them using a fragment, but > fragments are rife with issues, that I would not suggest them being used by > default. Yes, but administrators or infrastructure providers which are not OAuth experts or application specific experts will not expect that they have to create a specific rule for sanitizing this authorization code. Obviously, for me as a penetration tester, I like that, because this is a good justification for my work and I can prove this whenever I’m doing a penetration test. However, to me, world would feel much better if developers would be educated that at this point they should not rely on the administrator to set up the software correctly, but instead develop client software in a way that even the dumpest adminstrator is able to set up the software securely. And I think the best way to educate developers is the standard. > I feel like there are just too many caveats here, which each of their own > mitigations where the protocol need not be concerned with. > > > On Fri, Nov 7, 2025, 15:36 Primbs, Jonas <[email protected] > <mailto:[email protected]>> wrote: >> See comments inline. >> >>> Am 07.11.2025 um 08:41 schrieb Warren Parad <[email protected] >>> <mailto:[email protected]>>: >>> >>> Oh we're thinking the code ending up in the logs is a problem. But we're >>> limiting the concern to only the logs of the proxies and backend on >>> fetching the page, but logs can be generated by any number of tools so just >>> because it ends up in the reverse proxy's logs doesn't really seem like a >>> big concern. >> >> Yes, but the logs on the client are typically controlled by the client >> developer, right? >> So a well-informed developer could prevent the authorization server from >> being logged. That can be pretty much reduced to the point „do not use >> analytics on the callback URI endpoint“. >> >> For reverse proxies, for example, which are out of the control of the >> developers (think of on-premise deployments), this is not true. >> >>> And for logs, what's the expected exfiltration timeline? I can't imagine >>> auth codes being consumed by an attacker through that strategy before the >>> code expires. Are we really thinking that auth code exchange is being >>> compromised faster than that? >> >> „Near-real-time“. It must be within the authorization code’s validity >> period, which is at most 10 minutes according to RFC 6749. >> I have seen NGINX servers configured in the wrong way which allowed me to >> get access to the server logs from the web, which will then turn information >> leaks into critical attack vectors. >> We should also consider low-privileged log auditors (often seen in big >> companies) which have real-time access to the logs through a SIEM system. >> They can use this attack vector to trick high-privileged administrators into >> this browser-swapping attack which enables privilege escalation. >> >>> And if we're concerned with the reverse proxy, won't those same logs >>> include headers as well? >> >> Depends on the configuration. >> However, I’m pretty much concerned, that the authorization header will not >> be logged there because it is a header that is well-known to contain >> credentials, so many logging systems are aware that they must blank the >> value of that header out. >> For query parameters, this is not the case because query parameters are >> expected to can be shared as part of the entire URL. >> >>> On Fri, Nov 7, 2025, 14:37 Aaron Parecki <[email protected] >>> <mailto:[email protected]>> wrote: >>>> The URL is sent to the backend because the browser fetches the page at the >>>> URL from the backend. URL fragments are not sent to the server by >>>> definition. >>>> >>>> On Fri, Nov 7, 2025 at 8:35 AM Warren Parad <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> Can you explain further under what circumstance the url would be sent to >>>>> the backend and why in that circumstance the fragment would not be sent? >>>>> >>>>> >>>>> On Fri, Nov 7, 2025, 14:31 Primbs, Jonas <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>>> Fragment parameters are not transferred to the backend. They remain in >>>>>> the user's browser. >>>>>> This does not entirely solve the issue for web apps, but it reduces the >>>>>> attack surface because the attacker requires access to the user’s >>>>>> client, e.g., if they share the same workstation. >>>>>> I think for mobile apps, fragment almost solves the issue, because >>>>>> there’s no URL bar to enable URL sharing, no referer header, probably no >>>>>> analytics, and near-real-time log access is also difficult due to the >>>>>> isolation of apps and the fact that mobile devices are rarely shared >>>>>> between users. >>>>>> >>>>>> >>>>>> >>>>>>> Am 07.11.2025 um 07:50 schrieb Warren Parad <[email protected] >>>>>>> <mailto:[email protected]>>: >>>>>>> >>>>>>> How is fragment any different from query? >>>>>>> >>>>>>> On Fri, Nov 7, 2025, 13:45 Primbs, Jonas <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> Hi Warren, >>>>>>>> >>>>>>>> >>>>>>>>> Am 07.11.2025 um 04:36 schrieb Warren Parad >>>>>>>>> <[email protected] >>>>>>>>> <mailto:[email protected]>>: >>>>>>>>> >>>>>>>>> If PKCE fixes a problem, then that's the solution to the problem, it >>>>>>>>> doesn't make sense to add a "standard alternative" because of that. >>>>>>>>> State, never existed for CSRF protection, that was the nonce, which >>>>>>>>> has been deprecated with the introduction of PKCE, so neither S1 or >>>>>>>>> S3 are relevant right? >>>>>>>>> >>>>>>>> >>>>>>>> I also prefer always recommending PKCE, because it simplifies a lot, >>>>>>>> even in the rest of the draft. >>>>>>>> You mean S2 or S3, right? Because S1 is the PKCE solution. >>>>>>>> >>>>>>>>> I'm missing the value in a "revocation mechanism" for authorization >>>>>>>>> codes, if the attacker can block requests to the AS, then how would >>>>>>>>> the revocation mechanism end up getting called? What would trigger >>>>>>>>> that? >>>>>>>>> >>>>>>>> >>>>>>>> Tthat’s correct. If the authorization code revocation can be blocked >>>>>>>> by the attacker until the attacker requests the tokens, the protection >>>>>>>> is useless. >>>>>>>> Then the only solution is not disclosing the authorization code, e.g., >>>>>>>> by using response_mode=fragment for client-side mobile/web apps, or >>>>>>>> response_mode=form_post for server-side apps. >>>>>>>> If the client is running on the server side, I think it is unusual >>>>>>>> that the attacker can intercept or at least delay the authorization >>>>>>>> code revocation, because that would require the attacker to be between >>>>>>>> the client server and the authorization server. >>>>>>>> >>>>>>>> >>>>>>>>> On Fri, Nov 7, 2025 at 10:08 AM Frederik Krogsdal Jacobsen >>>>>>>>> <[email protected] >>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>> I think S1 is the best bet for a standard solution to mention in >>>>>>>>>> OAuth 2.1. >>>>>>>>>> State could be deprecated as a solution for CSRF protection, but it >>>>>>>>>> is still useful for other things. >>>>>>>>>> >>>>>>>>>> An AS could individually recommend variations on S2 if they do not >>>>>>>>>> plan to implement PKCE. >>>>>>>>>> >>>>>>>>>> I still think that a more general cancellation/revocation mechanism >>>>>>>>>> as mentioned by Max would be useful (also for other grant types such >>>>>>>>>> as auth_req_ids from CIBA), but I understand that introducing this >>>>>>>>>> is probably off-topic for this thread. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Frederik >>>>>>>>>> >>>>>>>>>> On Thu, 6 Nov 2025 at 17:43, Aaron Parecki >>>>>>>>>> <[email protected] >>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>> I think that's covered as part of the discussion of how a client >>>>>>>>>>> and AS know that each other are speaking OAuth 2.1 vs 2.0. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Nov 6, 2025 at 11:40 AM Neil Madden >>>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>>>> The only issue I have with deprecating state for CSRF protection >>>>>>>>>>>> is that the client has no way in general to know if the AS >>>>>>>>>>>> supports (in fact enforces) PKCE. If it doesn’t, then we may end >>>>>>>>>>>> up with no CSRF protection at all, and clients being vulnerable to >>>>>>>>>>>> Login CSRF/session fixation-like attacks. >>>>>>>>>>>> >>>>>>>>>>>> — Neil >>>>>>>>>>>> >>>>>>>>>>>>> On 6 Nov 2025, at 16:12, Aaron Parecki <[email protected] >>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> S1 seems like the cleanest solution to me. I think this should >>>>>>>>>>>>> also come with language officially deprecating "state" for CSRF >>>>>>>>>>>>> protection like Philippe said. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Nov 6, 2025 at 10:59 AM Primbs, Jonas >>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>> Let’s collect auth code revocation solutions: >>>>>>>>>>>>>> >>>>>>>>>>>>>> S1: Enforce PKCE + normal token request but without >>>>>>>>>>>>>> code_verifier. >>>>>>>>>>>>>> + No additional endpoints >>>>>>>>>>>>>> + Works for many existing implementations >>>>>>>>>>>>>> - AS must implement PKCE and enforce it for all clients (bad for >>>>>>>>>>>>>> testing) >>>>>>>>>>>>>> >>>>>>>>>>>>>> S2: Use specific client_id at the token endpoint. >>>>>>>>>>>>>> + No additional endpoints >>>>>>>>>>>>>> - A bit hacky >>>>>>>>>>>>>> >>>>>>>>>>>>>> S3: Specify a dedicated token endpoint >>>>>>>>>>>>>> + One official way >>>>>>>>>>>>>> - Huge changes required >>>>>>>>>>>>>> >>>>>>>>>>>>>> S4: Use token revocation endpoint >>>>>>>>>>>>>> + Just an extension of existing endpoints >>>>>>>>>>>>>> - Client cannot know if the AS implements this >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Am 06.11.2025 um 08:24 schrieb Neil Madden >>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This makes me wonder if we could in fact have a special >>>>>>>>>>>>>>> client_id value that indicates that the AS should revoke the >>>>>>>>>>>>>>> code (and any tokens if issues)? It's a bit hacky but has the >>>>>>>>>>>>>>> advantage of likely doing the right thing for most ASes, as Tim >>>>>>>>>>>>>>> mentions. Something like client_id=csrf_detected_revoke_please. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 6 Nov 2025, at 13:04, Tim Würtele >>>>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Jonas, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> a minor (but imho relevant to this discussion) nitpicking >>>>>>>>>>>>>>>> inline. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Tim >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 05.11.25 16:25, Primbs, Jonas wrote: >>>>>>>>>>>>>>>>> Hi Frederik, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> yes, calling the token request validly, thereby invalidating >>>>>>>>>>>>>>>>> the authorization code for future usage by the attacker, and >>>>>>>>>>>>>>>>> throwing away the token response could also be a solution. >>>>>>>>>>>>>>>>> However, I am not sure what the implications could be with >>>>>>>>>>>>>>>>> respect to how authorization servers handle this (e.g., >>>>>>>>>>>>>>>>> starting a session, which confuses users when they look at >>>>>>>>>>>>>>>>> the list of active sessions) or how clients handle this >>>>>>>>>>>>>>>>> (e.g., logging tokens in a potential crash dump). >>>>>>>>>>>>>>>>> If authorization servers implement token revocation >>>>>>>>>>>>>>>>> correctly, when authorization codes are used twice, sending a >>>>>>>>>>>>>>>>> second valid token request with the same authorization code >>>>>>>>>>>>>>>>> afterwards might ensure that the issued tokens cannot be used >>>>>>>>>>>>>>>>> anymore. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Again, this might fail if the client faces any issues. So I >>>>>>>>>>>>>>>>> prefer a standardized authorization code invalidation >>>>>>>>>>>>>>>>> mechanism. >>>>>>>>>>>>>>>>> One opportunity here, which is already standardized, is >>>>>>>>>>>>>>>>> enforcing PKCE and sending no code_verifier in the token >>>>>>>>>>>>>>>>> request intentionally. >>>>>>>>>>>>>>>> The issue with that is the (historically grown) lack of >>>>>>>>>>>>>>>> precision in the specs as to when exactly an authZ code is to >>>>>>>>>>>>>>>> be invalidated by the AS. Let me elaborate a bit: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> RFC 6749 says (in 4.x) the client MUST only use the code once >>>>>>>>>>>>>>>> and the AS MUST deny all but the first request with a given >>>>>>>>>>>>>>>> code (and SHOULD revoke associated tokens). In 10.5, we have >>>>>>>>>>>>>>>> "Authorization codes MUST be [...] single-use." - without >>>>>>>>>>>>>>>> being explicit about whether this statement applies to the >>>>>>>>>>>>>>>> "user" of the code (the client), the AS, or both; although I'd >>>>>>>>>>>>>>>> argue that interpreting this as "the client may only use it >>>>>>>>>>>>>>>> once" is a justifiable interpretation (especially because the >>>>>>>>>>>>>>>> subsequent sentences in 10.5 also just repeat the SHOULD >>>>>>>>>>>>>>>> statement from 4.x). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> RFC 6819, 4.4.1.1 does say "The authorization server should >>>>>>>>>>>>>>>> enforce a one-time usage restriction (see Section 5.1.5.4)."; >>>>>>>>>>>>>>>> but the language there is not normative ("may", "may want", >>>>>>>>>>>>>>>> ...); the same is true for 5.2.1.1. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> OIDC is even more vague (3.1.3.2): The AS MUST ... "If >>>>>>>>>>>>>>>> possible, verify that the Authorization Code has not been >>>>>>>>>>>>>>>> previously used." >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ... just a few examples. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Using PKCE does not change this ambiguity; RFC 7636 does not >>>>>>>>>>>>>>>> talk about code invalidation at all. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In other words: An error response from the AS's token EP, >>>>>>>>>>>>>>>> e.g., due to a wrong/missing code_verifier does not guarantee >>>>>>>>>>>>>>>> that the code has been invalidated. And as others have pointed >>>>>>>>>>>>>>>> out in this thread, there are AS implementations out there >>>>>>>>>>>>>>>> that do accept a code multiple times (be it "on purpose", or >>>>>>>>>>>>>>>> due to CAP). Of course, one might argue that these are not >>>>>>>>>>>>>>>> standards-compliant, but I don't think there's a very strong >>>>>>>>>>>>>>>> case for that claim, given the (historically) inaccurate >>>>>>>>>>>>>>>> wording... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That being said: If I were to implement a client today, I >>>>>>>>>>>>>>>> would make such a "wrong" token request to at least give the >>>>>>>>>>>>>>>> AS a chance of detecting the attack - and if the AS follows >>>>>>>>>>>>>>>> the SHOULD-advise from 6749, any tokens issued for that code >>>>>>>>>>>>>>>> would then immediately be invalidated, which of course does >>>>>>>>>>>>>>>> not prevent an attack, but may help to limit the damage. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Side note: This "best effort" damage control strategy does not >>>>>>>>>>>>>>>> even need PKCE, just sending the code with a wrong client_id >>>>>>>>>>>>>>>> should lead to the same result (from a "did the AS implement >>>>>>>>>>>>>>>> 6749's SHOULD" perspective). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If there already is a spec for that in CIBA, we should >>>>>>>>>>>>>>>>> include or at least reference this in the OAuth 2.1 spec. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Greetings, >>>>>>>>>>>>>>>>> Jonas >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Am 05.11.2025 um 04:02 schrieb Frederik Krogsdal Jacobsen >>>>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>>>> <mailto:[email protected]>: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Jonas, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks for the detailed explanation of the attack and >>>>>>>>>>>>>>>>>> possible mitigations. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It seems to me that your suggestion 3 could be implemented >>>>>>>>>>>>>>>>>> by the client by simply exchanging the code and throwing >>>>>>>>>>>>>>>>>> away the token response when the initial CSRF is detected. >>>>>>>>>>>>>>>>>> This would of course only work with an AS that correctly >>>>>>>>>>>>>>>>>> implements the security guidance in section 10.5 of RFC >>>>>>>>>>>>>>>>>> 6749: "Authorization codes MUST be short lived and >>>>>>>>>>>>>>>>>> single-use." >>>>>>>>>>>>>>>>>> The main problem with this approach is that it is a bit >>>>>>>>>>>>>>>>>> confusing to explain. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I also know that in practice, some AS implementers allow >>>>>>>>>>>>>>>>>> multiple uses of the code, so it may be interesting to look >>>>>>>>>>>>>>>>>> into defining a specific "cancel request" that uses up a >>>>>>>>>>>>>>>>>> code without returning a token. >>>>>>>>>>>>>>>>>> Defining such a request might also make the approach easier >>>>>>>>>>>>>>>>>> to explain. >>>>>>>>>>>>>>>>>> In fact, many OIDC providers already define custom "cancel" >>>>>>>>>>>>>>>>>> requests to mitigate phishing. A "cancel" request might also >>>>>>>>>>>>>>>>>> be useful for OpenID CIBA [1]. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Do you see any problems with this approach? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>> Frederik >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> [1]: >>>>>>>>>>>>>>>>>> https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, 4 Nov 2025 at 05:10, Primbs, Jonas >>>>>>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> according to Aaron’s recommendation, I have created a PR >>>>>>>>>>>>>>>>>>> for OAuth 2.1: >>>>>>>>>>>>>>>>>>> https://github.com/oauth-wg/oauth-v2-1/pull/230 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> It references OpenID Connect’s response modes (fragment and >>>>>>>>>>>>>>>>>>> form_post) as solutions for Browser-Swapping attacks, which >>>>>>>>>>>>>>>>>>> I have presented in today’s OAuth WG meeting. >>>>>>>>>>>>>>>>>>> If you have missed my presentation, but are still >>>>>>>>>>>>>>>>>>> interested, here are my slides: >>>>>>>>>>>>>>>>>>> https://datatracker.ietf.org/meeting/124/materials/slides-124-oauth-sessa-browser-swapping-01 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I’m interested in your feedback on this first draft, which >>>>>>>>>>>>>>>>>>> currently covers only recommendation #2 from my slides, >>>>>>>>>>>>>>>>>>> because this is probably the least controversial change. >>>>>>>>>>>>>>>>>>> If you are attending onsite, also feel free to speak to me >>>>>>>>>>>>>>>>>>> in the hallway. My company gave me enough of the „No, >>>>>>>>>>>>>>>>>>> PKCE…“ t-shirts for the rest of the week, so that it’s >>>>>>>>>>>>>>>>>>> easier for you to find me. @Brian & Mike: I have learned >>>>>>>>>>>>>>>>>>> from the best ;-) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Greetings, >>>>>>>>>>>>>>>>>>> Jonas >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Jonas Primbs M.Sc. >>>>>>>>>>>>>>>>>>> University of Tübingen >>>>>>>>>>>>>>>>>>> Faculty of Science >>>>>>>>>>>>>>>>>>> Department of Computer Science >>>>>>>>>>>>>>>>>>> Sand 13, 72076 Tübingen, Germany >>>>>>>>>>>>>>>>>>> <https://www.google.com/maps/search/Sand+13,+72076+T%C3%BCbingen,+Germany?entry=gmail&source=g> >>>>>>>>>>>>>>>>>>> Tel.: (+49) 7071 / 29-70512 >>>>>>>>>>>>>>>>>>> Mail: [email protected] >>>>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>>>>> Web: https://kn.inf.uni-tuebingen.de >>>>>>>>>>>>>>>>>>> <https://kn.inf.uni-tuebingen.de/> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Tim Würtele, M.Sc. >>>>>>>>>>>>>>>> Room V38 2.434 >>>>>>>>>>>>>>>> Institute of Information Security - SEC >>>>>>>>>>>>>>>> Universität Stuttgart >>>>>>>>>>>>>>>> Universitätsstraße 38 >>>>>>>>>>>>>>>> <https://www.google.com/maps/search/Universit%C3%A4tsstra%C3%9Fe+38?entry=gmail&source=g> >>>>>>>>>>>>>>>> D-70569 Stuttgart >>>>>>>>>>>>>>>> Germany >>>>>>>>>>>>>>>> Phone: +49 (0) 711 685-88468 >>>>>>>>>>>>>>>> https://sec.uni-stuttgart.de >>>>>>>>>>>>>>>> <https://sec.uni-stuttgart.de/>_______________________________________________ >>>>>>>>>>>>>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>>> <mailto:[email protected]> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>> >>>>>> >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
