Karl,
The topology correction is fair and I take it: "identities it did not mint"
describes the passthrough deployment, and your Owned/Brokered taxonomy makes
clear ID-JAG assumes the IdP establishes and owns the downstream identity even
where authentication is delegated upstream. With that scoping accepted, I think
we now agree on what the two shapes actually trade, and it is worth one
sentence for the record because it is sharper than my earlier framing: the
brokered model concentrates identity lifecycle authority (provisioning,
revocation, propagation) at the IdP for principals whose authentication lives
elsewhere; the direct model keeps lifecycle with the platform that mints. Which
placement a deployment wants is genuinely situational, which is why your shared
deployment-mode framing across the two drafts, WAG carrying the direct mode,
ID-JAG the IdP-integrated mode, with an aligned subject_token shape and shared
sub_profile vocabulary, seems exactly right to me, and better than either draft
absorbing the other.
On your question: sub_profile is the right construction for the own-behalf
side, with one condition that decides whether it is construction or convention.
A typed-principal claim plus the presence or absence of act is labeling; it
becomes construction-level when mode and evidence are required to agree and
disagreement fails closed: a token typed own-behalf that carries delegation or
actor evidence is rejected, not reinterpreted, and a token typed with-principal
that lacks the required evidence is rejected, not defaulted. If the processing
rules state that agreement normatively, and the registry records the
interaction rather than leaving it to per-deployment inference, then
sub_profile does the own-behalf job, at the grant layer and, as you say,
carried into RS-issued tokens so no one re-derives the mode from context
downstream.
The with-principal side needs the profile rather than the flag for a structural
reason worth naming: the requirements that case carries (the on-behalf-of
principal conveyed such that intermediaries cannot alter it, authorization on
the conjunction of agent permission and principal entitlement, execution-time
human-authorization evidence bound to the exact action) are invariants over
evidence, not attributes of a subject, and no typing claim can express them.
That is precisely the Actor Profile / delegation-evidence layer's job, and I
accept the alignment offer explicitly and gladly: the with-principal evidence
work I have in flight should align with Actor Profile at the semantic layer,
what a piece of delegation or authorization evidence asserts, who it binds,
what its consumption semantics are, while the two efforts can differ on
carriage and residency, which is where the deployment models legitimately
diverge. I would rather the ecosystem get one evidence semantics with two
conveyance profiles than two vocabularies, and I will coordinate before my
draft posts. I look forward to the Actor Receipts and Actor Proofs companions;
the names alone suggest we have been circling the same layer from two sides,
which is the best argument for aligning early.
And noted on draft-wzdk-scim-agent-resource; the lifecycle-propagation story
was the part of the brokered model I had not seen written down, and I will read
it.
Morgan
On Wednesday, August 5th, 2026 at 12:49 AM, Karl McGuinness
<[email protected]> wrote:
> Morgan,
>
> two topologies
>
> Aligned with the acquisition/binding framing (thanks, that was a useful
> sharpening). One clarification on the concentration critique though:
> "...issuer of record for identities it did not mint" applies to a different
> deployment than the topology ID-JAG assumes. In that deployment, the IdP
> issuing the ID-JAG mints the identity the RAS consumes, regardless of
> upstream credential or assertion. This holds for both patterns visible today
> in the user / on-behalf-of case, and extends to workload/agent Principals via
> work in flight:
>
> - IdP Owned Principal.The IdP authenticates the Principal directly and owns
> the identity end-to-end.
> - IdP Brokered Principal.The IdP delegates authentication upstream (SAML/OIDC
> federation for users, platform-issued credentials like Kubernetes
> ServiceAccounts / SPIFFE SVIDs for workloads/agents) but still establishes
> the downstream identity. The IdP propagates lifecycle changes to the RAS via
> SCIM (users today, agents
> via[draft-wzdk-scim-agent-resource](https://datatracker.ietf.org/doc/draft-wzdk-scim-agent-resource/))
> or JIT at first presentation.
>
> Both patterns apply to enterprise and platform IdPs. A platform IdP MAY
> delegate authentication upstream while remaining authoritative for the
> downstream identity, provided it owns that identity's lifecycle
> (provisioning, revocation, JIT) rather than acting as a pure passthrough. The
> "identities it did not mint" concern applies to the passthrough deployment,
> which I feel isn't a good fit for ID-JAG. RAS trust in the IdP largely rests
> on the IdP being the identity issuer of record downstream, not just a signing
> intermediary.
>
> claims vocabulary boundary
>
> Issue #73 as originally proposed spans both cases: an own-behalf mode (subis
> a workload/agent identifier typed viasub_profile, no user in the token) and
> an explicit-delegation mode (sub = user,act = client/workload). Your concern
> about the two vocabularies quietly merging applies to the union, and the same
> disambiguation problem doesn't stop at the ID-JAG assertion grant. Once the
> ID-JAG is exchanged at the Resource Authorization Server, the resulting
> access token also needs to distinguish own-behalf from with-principal, or
> every Resource Server ends up re-deriving it from context. This is what
> "distinguishable by construction" was meant to avoid.
>
> Explicit vocabulary for these distinctions ([Actor
> Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/)for
> delegation,[Entity
> Profiles](https://datatracker.ietf.org/doc/draft-mora-oauth-entity-profiles/)'sub_profile/client_profilefor
> Principal type) is designed to carry across both assertion grants and access
> tokens, keeping the distinction visible end-to-end if the RS profiles it in
> its issued tokens. Since a Resource Server sees a mix of own-behalf and
> with-principal tokens over time, the vocabulary is worth carrying at that
> layer regardless of grant.
>
> working position
>
> My working position on #73: the explicit-delegation piece was already moved
> to the[Actor
> Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/)family
> with its own claim vocabulary and processing rules, designed to compose with
> ID-JAG rather than replace it. Happy to align Actor Profile's evidence
> vocabulary with the separate with-principal work you have in flight. The
> point of separating Actor Profile from ID-JAG was to keep this vocabulary
> evolvable, with[Actor
> Receipts](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-receipts/)and[Actor
>
> Proofs](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-proofs/)added
> as companion drafts.
>
> What still seems to be valid for ID-JAG under #73 is the own-behalf
> extension: allowingsubject_tokento carry a client acting as itself, so a
> workload/agent Principal appears directly assub. This is where ID-JAG's
> coverage overlaps with WAG's scope, and where your "distinguishable by
> construction" concern applies most directly. Whether that lands as one draft
> or two aligned drafts is worth working through with the WG.
>
> Under #73,sub_profile(andclient_profile) are proposed for exactly this
> purpose: values likeuser,service,ai_agent, combined with the presence or
> absence ofact, give a construction-level distinction between own-behalf and
> with-principal at the grant layer, and at the access-token layer when the RS
> adopts the same vocabulary. This reduces the need for a RAS or Resource
> Server to infer from context.
>
> If there's WG interest, one direction would be a shared "deployment mode"
> framing across the two drafts, with WAG carrying the direct platform↔RAS mode
> and ID-JAG carrying the IdP-integrated mode, cross-referenced from each side.
> Aligning on a sharedsubject_tokenJWT shape andsub_profilevocabulary would let
> a RAS accepting either path apply the same processing rules.
>
> Issub_profile(typed Principal in the token) enough of a construction-level
> distinction on the own-behalf side, with Actor Profile or a related
> delegation-evidence profile carrying the with-principal side?
>
> -Karl
>
> On Tue, Aug 4, 2026 at 7:42 PM morganLR <[email protected]> wrote:
>
>> Paul, Karl, Aaron, Yaron,
>>
>> A few observations from the requirements side, since the draft was kind
>> enough to position against it.
>>
>> On the deployment-shape discussion: it may help to name what the two shapes
>> are actually deciding. In the vocabulary the requirements draft's -02
>> revision adopts, every cross-boundary trust story has an acquisition step
>> (how the relying side obtains trust material for an issuer at all) and a
>> binding step (whether that material represents the party it claims). WAG's
>> admin-level entry per tenancy performs both in one administrative act,
>> directly between platform and resource AS, and amortizes it across unbounded
>> ephemeral instances via just-in-time acceptance; the IdP-integrated shape in
>> issue #73 performs the same two steps once, between IdP and resource AS, and
>> then amortizes across platforms as well as instances. Both are
>> prior-arrangement models with different concentration trade-offs: the direct
>> shape keeps the trust decision with the party consuming it at the cost of
>> one entry per tenancy; the brokered shape collapses entries at the cost of
>> making the IdP the issuer of record for identities it did not mint and a
>> runtime dependency for every platform behind it. Which trade a deployment
>> wants seems genuinely situational, which argues for Paul's separate-draft
>> instinct with aligned token shape, rather than one model absorbing the
>> other. And for completeness: the case where no prior arrangement can exist
>> at all, first contact between organizations with no admin on either side to
>> perform the entry, is the lane the requirements draft exists for, and
>> neither shape here claims it.
>>
>> On claims vocabulary, one boundary drawn now will save this thread's
>> successors a painful divorce: WAG's scope is the agent acting as itself, no
>> human principal in the token, and the claims that case needs (instance
>> identity, tenancy, attestation context, the RFC 9068 authorization
>> attributes) are structurally different from the with-principal case, where
>> delegation and authorization evidence must be conveyed and where the
>> requirements impose invariants (principal binding and non-alterability along
>> the chain, dual-axis authorization, execution-time human-authorization
>> evidence) that own-behalf tokens never carry. Issue #73's relaxation of
>> subject_token toward client assertions and attestations is exactly where
>> these two vocabularies could quietly merge, and they should not: whatever
>> registry these claims land in, I would ask that own-behalf attributes and
>> with-principal delegation evidence be distinguishable by construction, not
>> by convention. The with-principal evidence vocabulary is adjacent work I
>> intend to bring forward separately, and I will keep it aligned with whatever
>> this thread settles for the own-behalf case.
>>
>> On Paul's question 3, briefly, because the working group just paid for this
>> lesson: audience handling should inherit rfc7523bis's sole-audience
>> discipline exactly, one audience, the token endpoint's issuer identifier, no
>> relaxation toward relationship-inferred audiences. The audience-injection
>> findings were about assertions consumable by parties other than the one
>> named, and a grant format born after the remedy should be strict from birth.
>>
>> And Yaron, thank you for the production datapoint; PoP-constrained grants
>> running at bank grade is evidence the whole space should be citing, and
>> cnf-in-the-grant seems clearly right for WAG as well.
>> Morgan
>> On Tuesday, August 4th, 2026 at 8:18 PM, Karl McGuinness
>> <[email protected]> wrote:
>>
>>> +1
>>>
>>> The changes we made to relax the definition of ID-JAG IdP from Enterprise
>>> IdP to as Aaron indicated, the role of identity issuer for the RAS, was to
>>> enable a "Kubernetes"-like deployment model with a Platform IdP. We also
>>> relaxed actor_token constraints to enable profiling ontop for instances.
>>>
>>> Issue #73 is just proposing to do the same for Principal and relaxing it to
>>> allow Client Assertion/Attesation/Client Instance Assertion as a
>>> subject_token instead of an id_token with the IdP brokering subject,
>>> claims, scopes. resource to the downstream RAS for client as subject.
>>>
>>> -Karl
>>>
>>> On Tue, Aug 4, 2026 at 6:06 PM Aaron Parecki <[email protected]> wrote:
>>>
>>>> fwiw a deployment option for ID-JAG could be a consumer platform issuing
>>>> ID-JAGs itself. This is outlined in appendix A.2
>>>> https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-04.html#appendix-A.2
>>>> but imagine the case where the "CIAM Platform" in that example is
>>>> actually the same platform as where the client is running. The key thing
>>>> is the relationship between the Resource AS and the ID-JAG issuer. The
>>>> "IdP" role in ID-JAG is not limited to being what you typically think of
>>>> as an enterprise IdP.
>>>>
>>>> On Tue, Aug 4, 2026 at 5:57 PM Paul Carleton <[email protected]> wrote:
>>>>
>>>>> Karl, I agree that shape sounds a lot like the "BYO-IdP" model listed in
>>>>> the open issue. A few things I want to be true:
>>>>>
>>>>> - An RS adopting ID-JAG has an easy time adapting to accept WAG (i.e.
>>>>> same / similar token shape + similar JIT semantics)
>>>>> - An RS adopting WAG has an easy time adapting to accept ID-JAG
>>>>> - An RS adopting WAG does not necessarily need to integrate with an IdP
>>>>>
>>>>> This last bullet point pushes me toward making this a separate draft. The
>>>>> initial and simplest deployment shape I am thinking of is similar to a
>>>>> kubernetes cluster's OIDC provider being used in a workload identity
>>>>> federation flow. In that deployment, the kubernetes cluster is not a
>>>>> full-blown IdP, it is just trusted to issue identities to its pods. There
>>>>> is no expectation that Kubernetes clusters register their pod identities
>>>>> with an IdP.
>>>>>
>>>>> Similarly the agent platform is not a full IdP, it is just responsible
>>>>> for giving identities to the agents in its domain. I agree that there are
>>>>> benefits to the IdP-integrated deployment model, but I want to allow for
>>>>> the simpler model initially.
>>>>>
>>>>> ID-JAG could also allow for platform's issuing their own non-IdP tokens,
>>>>> but that feels like bypassing the IdP when it is human-based access. With
>>>>> workloads, it feels more natural to have a deployment model with the
>>>>> platform being directly responsible for issuing tokens (similar to k8s
>>>>> oidc providers).
>>>>>
>>>>> That being said, the token shape, etc., should be similar regardless of
>>>>> which draft its specified in, so it seems worth aligning regardless of
>>>>> where it ends up. The claims I want to align on here would also be
>>>>> relevant to ID-JAG JIT provisioning.
>>>>>
>>>>> Yaron -- thanks for this. I agree we want PoP constraining. Re: [OAuth
>>>>> SPIFFE Client
>>>>> Authentication](https://www.ietf.org/archive/id/draft-ietf-oauth-spiffe-client-auth-02.html),
>>>>> I have sketched out the shapes
>>>>> [here](https://pcarleton.github.io/draft-carleton-workload-authz-grant/request-shapes.html).
>>>>> I think it solves a slightly different problem in that it relies on the
>>>>> RS understanding the SPIFFE credential, where in this case I want the WAG
>>>>> to be compatible with SPIFFE but not require SPIFFE. I would lean more
>>>>> towards CIMD + private_key_jwt for this particular pattern.
>>>>>
>>>>> On Mon, Aug 3, 2026 at 5:20 PM Yaron ZEHAVI
>>>>> <[email protected]> wrote:
>>>>>
>>>>>> Hello everyone,
>>>>>>
>>>>>> This looks like a useful addition to [OAuth SPIFFE Client
>>>>>> Authentication](https://www.ietf.org/archive/id/draft-ietf-oauth-spiffe-client-auth-02.html),
>>>>>> which also uses workload identity as RFC7521/3 assertion JWTs, but
>>>>>> stops short of using them as JAGs, rather focuses on client
>>>>>> authentication for other grants.
>>>>>>
>>>>>> A couple remarks:
>>>>>>
>>>>>> - This draft feels more naturally positioned as another profile of
>>>>>> [identity
>>>>>> chaining](https://www.ietf.org/archive/id/draft-ietf-oauth-identity-chaining-17.html),
>>>>>> alongside [ID
>>>>>> JAG](https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html).
>>>>>> The latter originates from challenges of streamlining cross-domain SSO
>>>>>> for humans by removing friction, and now tackles further aspects in this
>>>>>> space such as required claims for JIT user provisioning, deferred
>>>>>> responses etc.
>>>>>> - The JAG should be PoP constrained, which is easily achievable by
>>>>>> including the agent’s cnf claim in it. This mechanism is proposed by
>>>>>> [OAuth 2.0 JWT Authorization Grant with DPoP
>>>>>> Binding](https://www.ietf.org/archive/id/draft-parecki-oauth-jwt-dpop-grant-01.html)
>>>>>> and we use it with good results in applicable JAG flows in our company.
>>>>>>
>>>>>> Yaron
>>>>>>
>>>>>> Classification: GENERAL
>>>>>>
>>>>>> From: Karl McGuinness <[email protected]>
>>>>>> Sent: Monday, August 3, 2026 9:47 PM
>>>>>> To: Aaron Parecki <[email protected]>
>>>>>> Cc: Paul Carleton <[email protected]>; [email protected]
>>>>>> Subject: [OAUTH-WG] Re: New I-D: draft-carleton-workload-authz-grant
>>>>>> (Workload Authorization Grant)
>>>>>>
>>>>>> This message is from an external sender - be cautious, particularly with
>>>>>> links and attachments.
>>>>>>
>>>>>> I didn't see it as out of scope for ID-JAG because it's still acting as
>>>>>> a principal managed by the IdP across domains which could have RAS
>>>>>> specific subject identifiers and authorization claims. IdPs already need
>>>>>> to solve the challenge of managing different principal types, lifecycle,
>>>>>> entitlements, provisioning, etc. Its reduces a lot of cognitive overhead
>>>>>> for the developer to just think of ID-JAG as SSO where the upstream IdP
>>>>>> manages all the identity complexity as I just need issuer scoped `sub` I
>>>>>> can use for subject resolution. I acknowledge that my take my not be
>>>>>> shared which is why I was hoping to get more attention on the issue.
>>>>>>
>>>>>> On Mon, Aug 3, 2026 at 12:36 PM Aaron Parecki <[email protected]> wrote:
>>>>>>
>>>>>>> That's basically how we were thinking of it. I just felt like it was
>>>>>>> something a bit out of scope of the ID-JAG spec. But the idea is very
>>>>>>> much to reuse the existing relationship established between the
>>>>>>> Resource AS and IdP for ID-JAGs, and reuse it for workloads as well.
>>>>>>>
>>>>>>> On Mon, Aug 3, 2026 at 12:33 PM Karl McGuinness
>>>>>>> <[email protected]> wrote:
>>>>>>>
>>>>>>>> Paul,
>>>>>>>>
>>>>>>>> Interesting draft. I'll have to dive in deeper. My initial reaction is
>>>>>>>> that this draft lines up with something I raised in ID-JAG issue #73
>>>>>>>> (https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/issues/73):
>>>>>>>> whether ID-JAG should also cover workloads acting as themselves. The
>>>>>>>> issue sketches Workload and Agent Identity SSO modes where the
>>>>>>>> assertion's sub is the workload or agent itself rather than a chained
>>>>>>>> user identity, which is the same shape as your grant. The appeal of
>>>>>>>> reusing ID-JAG was one simple SSO model for agents, workloads, and
>>>>>>>> clients, whether acting on behalf of a user or as themselves, and it
>>>>>>>> stays aligned with the standard identity and authorization claims
>>>>>>>> (which also bears on your question 2).
>>>>>>>>
>>>>>>>> The deployment I was picturing looks a lot like the Enterprise IdP
>>>>>>>> variant in your issuer-placement open issue: the workload brings its
>>>>>>>> credential to the IdP (a WIMSE WIT, say), the IdP issues the grant,
>>>>>>>> and the platform picks it up by token exchange. If the resource AS is
>>>>>>>> already integrated with the IdP, things get simpler, since the IdP is
>>>>>>>> already handling agent lifecycle, entitlements, and governance through
>>>>>>>> SCIM or JIT. The resource AS ends up with one federation relationship
>>>>>>>> instead of an allowlist entry per platform.
>>>>>>>>
>>>>>>>> Would love to hear your thoughts, as there was some initial positive
>>>>>>>> signal on #73 but I was hoping for a larger discussion on the topic.
>>>>>>>>
>>>>>>>> Karl
>>>>>>>>
>>>>>>>> On Mon, Aug 3, 2026 at 11:06 AM Paul Carleton
>>>>>>>> <[email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Good to meet many of you in Vienna!
>>>>>>>>>
>>>>>>>>> I've posted an early individual draft based on some discussions had
>>>>>>>>> over that week. The draft profiles RFC 7523 for agent platforms: an
>>>>>>>>> agent obtains access tokens by presenting a platform-signed JWT
>>>>>>>>> authorization grant at the resource's authorization server. I've also
>>>>>>>>> posted this to wimse@, since the identity in the grant is a WIMSE
>>>>>>>>> workload identity produced by ordinary WIMSE issuance and
>>>>>>>>> cross-domain federation; this draft covers the OAuth-facing hop where
>>>>>>>>> an existing AS consumes it.
>>>>>>>>>
>>>>>>>>> This defines no new grant type, no new token format, and no change to
>>>>>>>>> RS-to-AS trust. A service with an existing OAuth deployment changes
>>>>>>>>> only its token endpoint. Trust is one admin-level entry per customer
>>>>>>>>> tenancy with keys resolved by reference, and the AS accepts
>>>>>>>>> previously-unseen subjects under a trusted issuer just in time; there
>>>>>>>>> is no client registration step.
>>>>>>>>>
>>>>>>>>> Relative to adjacent work: same JWT-authorization-grant shape as
>>>>>>>>> ID-JAG and draft-ietf-oauth-identity-chaining, but the subject is the
>>>>>>>>> agent workload itself rather than a chained user identity. The
>>>>>>>>> agent-as-client alternative (spiffe-client-auth,
>>>>>>>>> attestation-based-client-auth, CIMD) is addressed in question 1 below.
>>>>>>>>>
>>>>>>>>> Datatracker:
>>>>>>>>> https://datatracker.ietf.org/doc/draft-carleton-workload-authz-grant/
>>>>>>>>> Editor's copy:
>>>>>>>>> https://pcarleton.github.io/draft-carleton-workload-authz-grant/draft-carleton-workload-authz-grant.html
>>>>>>>>> Repo: https://github.com/pcarleton/draft-carleton-workload-authz-grant
>>>>>>>>>
>>>>>>>>> Feedback I'm most looking for:
>>>>>>>>>
>>>>>>>>> 1. The draft treats the agent as the grant subject, not a new client
>>>>>>>>> ID per-instance, and I think that's the right shape; thank you Brian
>>>>>>>>> Campbell for nudging me in that direction. It's one concrete stance
>>>>>>>>> in the ongoing client-instance discussion: consistent with the
>>>>>>>>> adopted stack (ATTEST, spiffe-client-auth, and the McGuinness drafts
>>>>>>>>> all keep one logical client_id and surface the instance elsewhere),
>>>>>>>>> and it keeps the adoption floor at "jwt-bearer, which already ships
>>>>>>>>> everywhere." Additional support for that framing would be helpful, or
>>>>>>>>> for concrete scenarios where subject-not-client breaks down.
>>>>>>>>>
>>>>>>>>> 2. Claim naming for platform-asserted attributes: reuse the RFC 9068
>>>>>>>>> roles/groups/entitlements registrations, or register new names?
>>>>>>>>> (Related question posed to wimse@ about whether the AIMS work wants
>>>>>>>>> to own this vocabulary.)
>>>>>>>>>
>>>>>>>>> 3. Input on Audience handling relative to rfc7523bis.
>>>>>>>>>
>>>>>>>>> Requested cluster: Cross-Domain Chaining. Related: Client
>>>>>>>>> Authentication.
>>>>>>>>>
>>>>>>>>> Most sections are deliberately TODO. Feedback here or on the repo is
>>>>>>>>> welcome.
>>>>>>>>>
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list -- [email protected]
>>>>>>>>> To unsubscribe send an email to [email protected]
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list -- [email protected]
>>>>>>>> To unsubscribe send an email to [email protected]
>>>>>>
>>>>>> This message and any attachment ("the Message") are confidential. If you
>>>>>> have received the Message in error, please notify the sender immediately
>>>>>> and delete the Message from your system, any use of the Message is
>>>>>> forbidden. Correspondence via e-mail is primarily for information
>>>>>> purposes. RBI neither makes nor accepts legally binding statements via
>>>>>> e-mail unless explicitly agreed otherwise. Information pursuant to § 14
>>>>>> Austrian Companies Code: Raiffeisen Bank International AG; Registered
>>>>>> Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number:
>>>>>> FN 122119m at the Commercial Court of Vienna (Handelsgericht Wien)._______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
