[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

Isn't that covered by Token Exchange already? https://datatracker.ietf.org/doc/html/rfc8693 Le sam. 18 mai 2024, 16:29, Igor Janicijevic a écrit : > Dear All, > > > > I have published an Internet Draft document that I would like to introduce > to the OAuth working group for consideration. Here

Re: [OAUTH-WG] OAuth Digest, Vol 187, Issue 6

That's a bit extreme. Can't an admin just unsubscribe him? Cc: oauth-ow...@ietf.org Le dim. 5 mai 2024, 21:57, Warren Parad a écrit : > I just marked it as spam, so his domain can deal with that. If everyone > does it, the domain may be permanently denylisted. > > On Sun, May 5, 2024 at 9:50 

Re: [OAUTH-WG] OAuth for Browser-Based Apps Draft 12

n a browsing context" or possibly "code executed in a document context" (or just "in a document"?), as opposed to a "worker context" or service worker. Anyway, thanks for that work. I'm only using the drafts as reference in architecture discussions and am looking forward t

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

re a >> specific code_challenge_method from the client and the authorization >> behaves as described in the example, PKCE does not protect from Login-CSRF. >> >> I think the following mitigations are possible: >> >>1. Enforce usage of PKCE in the client configuration in the >>Authorization Server >>2. Implementation of the authorization server returns an error in the >>Access Token Response when code_verifier is present in the token request, >>but no code_challenge and code_challenge_method is present in the >>authorization request. >>3. Additionally, when the behavior of an AS is correct (verification >>of code_verifier fails when no code_challenge was present), a client that >>relies on PKCE for CSRF protection must always include a code_verifier >>parameter in the token request (even if no code_verifier is present on the >>client side). >> >> >> >> Best regards, >> >> >> >> Benjamin Häublein >> Senior Consultant >> >> cirosec GmbH >> Ferdinand-Braun-Strasse 4 >> 74074 Heilbronn >> Germany >> Phone: +49 (7131) 59455-74 >> Fax: +49 (7131) 59455-99 >> Mobile: +49 (151) 122414-74 >> www.cirosec.de >> >> HRB Stuttgart 107883 >> CEO Stefan Strobel, CFO Peter Lips >> >> >> >> >> >> ___ >> >> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web apps BCP feedback

raditional defences. > +1, just mentioning that there should be CSRF mitigations in place should be enough IMO. Also maybe mention that securing the API is then actually outside the scope of the BCP (whose role in this case is only to recommend *not* using OAuth) -- Thomas Broyer /tɔ

[OAUTH-WG] Spam apparently coming from my email address

Hi all, Someone's apparently sending spam through this list using my email address as the sender. I'm obviously not the author of those. Could some of you please send me the full spam mail (with full mail headers) ? Thank you in advance and sorry for the inconvenience but I don't think I can

Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)

on an attacker "guessing" it should not be seen as a > security countermeasure. This section of RFC7009 will be referenced in a > subsequent errata. > > > > Instructions: > > - > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to di

Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

On Sun, Oct 4, 2020 at 6:55 PM Nicolas Mora wrote: > Hello, > > Le 20-10-04 à 11 h 27, Thomas Broyer a écrit : > > > There might be some kind of pushed events between the AS and the RS > when > > a JWT AT is revoked, to allow the RS not to introspect a JW

Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

Disclosure: I have not read the draft on JWT AT, those comments are based only on my current knowledge of OAuth 2.0 / OpenID Connect, and JWT. Le sam. 3 oct. 2020 à 19:18, Nicolas Mora a écrit : > My 2 cents, > > Le 20-10-02 à 18 h 19, Andrii Deinega a écrit : > > > > Here is what I would like

Re: [OAUTH-WG] [Editorial Errata Reported] RFC8252 (5776)

Hi Megan, On Thu, Jul 11, 2019 at 5:18 AM Megan Ferguson wrote: > Hi Jan, > > Please note that this errata report has been removed. As stated at > https://www.rfc-editor.org/errata.php: > > "Errata are for the RFCs as available from rfc-editor.org." > Well, fwiw, the issue is also present in

Re: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps

On Wed, May 8, 2019 at 9:38 AM Emond Papegaaij wrote: > In our case or AS might have to federate the authentication to some other > AS, > that would only work in an iframe. Therefore, I think we will go for the > OIDC > prompt=none in a hidden iframe. I'm not sure what to do if the AS reports >

Re: [OAUTH-WG] How to deal with multi-valued request parameters in a JAR (draft-ietf-oauth-jwsreq-17)?

for extensions > like resource indicators and token exchange to have multiple instances of a > parameter value without having to invent some new scheme to encode or > delimit multiple values. > > On Mon, Apr 22, 2019 at 7:52 AM Thomas Broyer wrote: > >> RFC6749 makes it clear

Re: [OAUTH-WG] Refresh Token Expiration

Yes, that was with the default cookie policy (on a coworker's macbook, and he doesn't use safari as his main browser) On Wed, Nov 28, 2018 at 11:20 AM Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > with the default cookie policy? > > > Am 23.11.2018 um 14:34 sch

Re: [OAUTH-WG] Refresh Token Expiration

Just tested my OpenID Connect Session Management implementation with Safari 12.0.1 and it works like a charm. On Thu, Nov 22, 2018 at 8:09 PM George Fletcher wrote: > My understanding is that cookies are not blocked on redirects > (IPT2/Safari) but I haven't done extensive testing. So from a

Re: [OAUTH-WG] Refresh Token Expiration

On Thu, Nov 22, 2018 at 5:50 AM Torsten Lodderstedt wrote: > Hi George, > > > Am 20.11.2018 um 22:15 schrieb George Fletcher : > > > > OIDC provides a "prompt=none" mechanism that allows the browser app to > request a new token in a hidden iframe. OAuth2 doesn't describe this flow.. > Note that

Re: [OAUTH-WG] Refresh Token Expiration

Fwiw, this is something I thought about for Ozwillo but never ended up implementing (though that still could happen): always issuing a refresh token (vs. only when scope includes offline_access nowadays) but bind its lifetime to the session when not offline_access. I would then revoke the refresh

Re: [OAUTH-WG] Inconsistent error responses between 6749 and 6750

On Mon, Sep 17, 2018 at 3:46 PM George Fletcher wrote: > Hi, > > It appears that RFC 6749 and RFC 6750 are inconsistent in regards to the > HTTP status code that should be returned when a requested scope is > "invalid". > > For example, if a call is make to the /token endpoint to obtain a new >

Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-discovery

Le mar. 10 juil. 2018 21:55, Andres Torres a écrit : >If the issuer identifier value contains a path component, any >terminating "/" MUST be removed before inserting "/.well-known/" and >the well-known URI suffix between the host component and the path >component. > > > Just as

Re: [OAUTH-WG] Token Revocation error codes

IFF the server processes it! RFC 7009 says “An authorization server MAY ignore this parameter, particularly if it is able to detect the token type automatically.” which BTW is exactly my case. For months, my AS received requests with token=Array, and now receives requests with token=null. Those

Re: [OAUTH-WG] Questions on urn:ietf:wg:oauth:2.0:oob

To my knowledge, it's been replaced with RFC 8252. See https://developers.google.com/identity/protocols/OAuth2InstalledApp (notice the deprecation notices in options 3 and 4 in the "create authorization credentials" section; you can find the "oob" URN later in the doc, associated with the same

Re: [OAUTH-WG] Obtaining authorized scopes

Are you looking for Token Introspection? https://tools.ietf.org/html/rfc7662 On jeu. 24 août 2017 00:21 Malla Simhachalam wrote: > Hi, > > We have an OAuth token revocation specification to revoke consents from an > external/relying party with a given token. I am

Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST

Rejecting a GET with code in the URL means that the code is never "used" at the AS, so can still be exchanged for an access token; and rejecting the request does not mean it won't leak. So reject if you like from the user's point of view, but "consume" the code anyway (and then immediately revoke

Re: [OAUTH-WG] Device flow feedback

Wouldn't expired_token be appropriate here? On Wed, Jul 5, 2017 at 12:02 PM Chris Needham wrote: > Hi, > > I'm one of the contributors to the ETSI Cross Platform Authentication spec > [1], which was based on an early draft of the OAuth 2.0 Device Flow. > > One of the

Re: [OAUTH-WG] token revocation from a different client

On Wed, May 31, 2017 at 12:01 PM Jaap Francke wrote: > Hi all, > > It’s only since recently that I’m sticking my nose deeper into the various > OAUTH (draft) specifications. > I also recently joined this mailing list. > I have a question and I hope someone can help me.

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

The client app could (and should) do a window.location.replace or window.history.replaceState to remove the entry from the browser history. AFAICT, this is out of scope of the OAuth specs because they're about the protocol and interactions between the parties involved, not about securing each one

Re: [OAUTH-WG] State Leakage Attack

e: a) the value is the same, as it leaked and the attacker reinjected the leaked value, and b) the client didn't invalidate the value after first use in step 1. > Am 23.04.2016 um 15:53 schrieb Thomas Broyer: > > > > On Sat, Apr 23, 2016 at 12:57 PM Torsten Lodderstedt < > tors...@l

Re: [OAUTH-WG] State Leakage Attack

On Sat, Apr 23, 2016 at 12:57 PM Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi Guido, > > do I get it right. The attacker is supposed to use the state value in > order to overwrite the user agent's session state? > Most apps only ever remember a single access token, so by re-using

Re: [OAUTH-WG] State Leakage Attack

On Sat, Apr 23, 2016 at 12:49 PM Guido Schmitz wrote: > Hi Torsten, > > as the state value is supposed to protect the user agent's session > against CSRF attacks, an attacker can use the leaked state value to > perform a CSRF attack against this user agent. > > The attacker

Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"

Note that goal #2 is already taken care of by introspection (endpoint varying response depending on authenticated client/RS), so maybe should be refined here. Le jeu. 17 mars 2016 18:44, George Fletcher a écrit : > Goals: > > 1. Help the client not send a token to the "wrong"

Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"

On Fri, Mar 18, 2016 at 1:50 PM George Fletcher wrote: > I was thinking of goal #2 as addressing the issue of audience in the > token. If the RS "authenticates" itself when calling introspection, then > the AS could apply the audience restriction for the RS. Is that what you >

Re: [OAUTH-WG] When does RS not require token introspection ?

lients now have to do the token exchange and keep track of both tokens. > — Justin > > On Mar 15, 2016, at 12:34 PM, Thomas Broyer <t.bro...@gmail.com> wrote: > > > > On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin <sberyoz...@gmail.com> > wrote: > >>

Re: [OAUTH-WG] Multiple authorization servers for one resource server

On Sun, Mar 13, 2016 at 2:03 AM Justin Richer wrote: > What we've done in deployments is to combine JWT and introspection. You > have all of your servers issue signed JWTs that include the "iss" (issuer) > in the body, signed with the key of the AS. The tokens also include a >

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

On Sat, Mar 12, 2016 at 6:01 PM Anthony Nadalin wrote: > This is not discovery, its simply metadata, […], I don’t understand the > rush to get this document out when we already know it’s incomplete > +1 ___ OAuth mailing list

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I agree with Samuel's comments wrt jwks_uri and registration_endpoint; and support the name change to “OAuth 2.0 Authorization Server Discovery Metadata” (or possibly “OAuth 2.0 Authorization Server Discovery”; but I'd rather narrow down the scope to only talk about metadata, without discovery

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

On Mon, Feb 29, 2016 at 11:35 PM Brian Campbell wrote: > +1 for "OAuth 2.0 Authorization Server Discovery” from those two options. > > But what about "OAuth 2.0 Authorization Server Metadata”? > > The document in its current scope (which I agree with, BTW) isn't

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

On Thu, Feb 25, 2016 at 4:25 PM George Fletcher wrote: > Interesting... this is not at all my current experience:) If a RS goes > from v2 of it's API to v3 and that RS uses the current standard of putting > a "v2" or"v3" in it's API path... then a token issued for v2 of the API

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Hi Nat, On Wed, Feb 24, 2016 at 12:54 PM Nat Sakimura <sakim...@gmail.com> wrote: > > 2016年2月22日(月) 18:44 Thomas Broyer <t.bro...@gmail.com>: > > >> (well, except if there are several ASs each with different scopes; sounds >> like an edge-case to me

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Couldn't the document only describe the metadata? I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration". The metadata described here would then either be used

Re: [OAUTH-WG] OAuth 2.0 for Native Apps: Call for Adoption Finalized

Fwiw, French govt's FranceConnect, which uses OpenID Connect, has sample apps using web views, and not using PKCE :-( (haven't looked in more details; don't know whether their AS supports PKCE). I just implemented PKCE in Ozwillo 10 days ago after reading this doc. I still have some work to do to

Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Le dim. 14 févr. 2016 02:40, William Denniss a écrit : > On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones > wrote: > >> It's an acceptable fallback option if the working group decides it >> doesn't want to register the values that are already in

Re: [OAUTH-WG] Authentication Method Reference Values spec incorporating adoption feedback

So, you just removed every relationship to OAuth (and the note about OAuth and authentication seems a bit out of context), and I thus wonder why the OAuth WG would adopt this draft; that'd rather be a JOSE thing. Le ven. 12 févr. 2016 07:03, Mike Jones a écrit : >

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

On Wed, Jan 27, 2016 at 1:54 PM George Fletcher wrote: > The difference might be whether you want to store the scope consent by > client "instance" vs client_id application "class". > Correct me if I'm wrong but this only makes sense for "native apps", not for web apps, right?

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

separate database object for storing them. I wouldn’t recommend simply > > updating an access token that’s already in the wild with more power — > > that just sounds wrong. > > > > — Justin > > > >> On Jan 26, 2016, at 1:57 PM, Thomas Broyer <t.bro...@gmail.com > >

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

Fwiw, at Ozwillo, we track grants per user per client_id (we don't support native apps; only web flows for now), and we don't do "incremental grants" like Google: if you request scope B and the user had only granted scope A, you'll get a token for scope B only. This is partly because our tokens

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Hi John, Le jeu. 21 janv. 2016 15:42, John Bradley a écrit : > We merged the state verification in with this rather than forcing people > to also look at the JWT encoded State draft. > https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state. > > While JWT encoded

Re: [OAUTH-WG] hijacking client's user account

Also, this is not news: http://securityintelligence.com/spoofedme-social-login-attack-discovered-by-ibm-x-force-researchers/ On Wed, Apr 22, 2015 at 5:02 PM Justin Richer jric...@mit.edu wrote: This seems to be not a problem with OAuth but with misusing OAuth as an authentication protocol:

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-04.txt

Hi, A couple editorial remarks: When introducing the first 2 examples, maybe merge the two paragraphs, starting with The following non-normative example shows …. Similarly, you talk about line wraps for display purpose but the examples don't need/use wrapping. Other than that, ready to go to

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-02.txt

A few notes on the form only (not the content): HTTP no longer is RFC 2616, it's RFC 7230 through 7237 (7235 and 7236 actually replacing 2617). Specifically, the GET and POST methods are defined in RFC 7231. application/x-www-form-urlencoded refers to RFC 1866; the same media type is said to be

Re: [OAUTH-WG] Notes on draft-ietf-oauth-introspection-01

On Tue Dec 02 2014 at 19:53:27 Richer, Justin P. jric...@mitre.org wrote: Thomas, thanks for the review. Responses inline. On Dec 2, 2014, at 11:08 AM, Thomas Broyer t.bro...@gmail.com wrote: The methods of managing and validating these authentication credentials are out of scope

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

So what? The request is OK (no missing parameter, etc.) so a 400 is not appropriate (it could still be used, but you couldn't tell what went wrong without *also* having some well-defined error response document format; and an invalid_token error code wouldn't work if you're also using token

Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item

of your case and we can tell what the best pattern is. Phil On Jul 29, 2014, at 17:55, Thomas Broyer t.bro...@gmail.com wrote: Try it where? When you're the RS trying to determine whether you should accept the token or reject it? Le 30 juil. 2014 02:49, Mike Jones michael.jo

Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item

] *On Behalf Of *George Fletcher *Sent:* Tuesday, July 29, 2014 3:25 PM *To:* Phil Hunt; Thomas Broyer *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item We also have a use case where the AS is provided

Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item

*Sent:* Tuesday, July 29, 2014 3:25 PM *To:* Phil Hunt; Thomas Broyer *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item We also have a use case where the AS is provided by a partner and the RS

Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item

/edits/comments on the document, please send these comments along to the list in your response to this Call for Adoption. Ciao Hannes Derek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Thomas Broyer

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of OAuth, and I don't see a good argument for doing this work in this working group. -- Justin On Jul 22, 2014, at 4:30 AM, Thomas Broyer t.bro...@gmail.com wrote: On Mon, Jul 21

Re: [OAUTH-WG] FW: New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

The end of section 2.2 talks about prompt=consent but the value is not defined above. Also, I don't understand the note about pwd being used by a service. In which scenario would that happen? Finally, what's the difference between providing several values for amr with and without including mfa?

Re: [OAUTH-WG] Token revocation endpoint - revoking access token vs. revoking the grant

from the refresh token returned at the same time) . If you send the access token for revocation, then only the access token will be revoked. Did I miss something? -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ ___ OAuth mailing

Re: [OAUTH-WG] New Token Introspection Draft

I thought someone mentioned it already: in the example you might want to send the request to /introspect instead of /register. It would be good to see user_id returned in the example too to get a better sense of what it really means (as I understand it, it's the username the user uses to sign in

Re: [OAUTH-WG] Another question on RFC 7009

FWIW, we return unauthorized_client. Le 31 janv. 2014 18:06, Todd W Lainhart lainh...@us.ibm.com a écrit : ...what's the intended way that the request is refused and the client is informed of the error when the the token was not issued to the client making the revocation request? We return

Re: [OAUTH-WG] Scopes in access token response

Le 3 déc. 2013 12:56, Andreas Kohn andreas.k...@gmail.com a écrit : Hi, the current RFC for OAuth 2.0 (http://www.rfc-editor.org/rfc/rfc6749.txt) is very unclear on *how* to return the scope in the access token response if there are multiple scopes requested/returned. I think it's very clear,

Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04

it, everybody uses bearer tokens nowadays, and the approach is the same as with jwt-bearer) Have I missed something? -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman

Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04

. I had already read that RFC but somehow forgot about some details, and failed to check it back for that particular problem. -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org

Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04

On Thu, Oct 24, 2013 at 4:36 PM, Richer, Justin P. jric...@mitre.orgwrote: On Oct 23, 2013, at 5:27 PM, Thomas Broyer t.bro...@gmail.com wrote: On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. jric...@mitre.orgwrote: Hi Thomas, You're right in that the introspection process is about

Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04

Le 25 oct. 2013 19:28, Torsten Lodderstedt tors...@lodderstedt.net a écrit : Am 25.10.2013 11:19, schrieb Thomas Broyer: On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi Thomas, we generate access tokens per resource server in order to mitigate

Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04

On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. jric...@mitre.orgwrote: Hi Thomas, You're right in that the introspection process is about getting meta data about a particular token by making an authenticated call. It does reveal a lot of information about the token -- because that's

Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04

On Wed, Oct 23, 2013 at 8:37 PM, Eve Maler e...@xmlgrrl.com wrote: Hi Thomas-- You may want to take a look at UMA, which leverages both OAuth and Justin's token introspection draft. Token introspection on its own is a shallow kind of loose coupling between authorization servers and resource

[OAUTH-WG] Comments on draft-richer-oauth-introspection-04

goal. Should I go with introspection? (maybe I misunderstood something, or saw a threats where there isn't) or should I use something else? Does my initial idea make sense? Should I go with it? -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je