Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08

From: Jaap Francke <[email-masked]>
Date: Mon, 2 Mar 2020 09:34:51 +0000

Hi Ben,

I saw your question and by coincidence i had just been doing some reading in RFC7662.
Maybe this helps.

Could you give me a pointer where in the text it says that if "active" is
false, no other claims are present?  ("active" only appears three times,
but none of them seem to say this.)

https://tools.ietf.org/html/rfc7662#page-12 says:

   To avoid disclosing the internal state of the authorization server,
   an introspection response for an inactive token SHOULD NOT contain
   any additional claims beyond the required "active" claim (with its
   value set to "false”).

Regards, jaap Francke

---

From: isaac ajonibode <[email-masked]>
Date: Thu, 12 Mar 2020 15:25:47 +0100

Please unsubscribe me from your mailing list

Isaac O.Ajonibode
C.Director CBMC Nigeria
[email-masked]
www.cbmcint.com/Nigeria
+2347087552127

FOUNDER/CEO
AJOFOLU VENTURES INT'L LTD
[email-masked]
+2348164286235
2 Corinthians 5:20

On Mon, 2 Mar 2020, 06:33 , <[email-masked]> wrote:

> Send OAuth mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>    1. Re: Benjamin Kaduk's Discuss on
>       draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and
>       COMMENT) (Benjamin Kaduk)
>    2. Re: OAuth 2.0 Token Introspection in RFC7662 : Refresh token?
>       (David Waite)
>    3. Re: OAuth 2.0 Token Introspection in RFC7662 : Refresh token?
>       (Andrii Deinega)
>    4. Re: OAuth 2.0 Token Introspection in RFC7662 : Refresh token?
>       (David Waite)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 1 Mar 2020 17:03:41 -0800
> From: Benjamin Kaduk <[email-masked]>
> To: Torsten Lodderstedt <[email-masked]>
> Cc: The IESG <[email-masked]>,
>         [email-masked],
>         [email-masked], oauth <[email-masked]>, Rifaat Shekh-Yusef
>         <[email-masked]>, Roman Danyliw <[email-masked]>
> Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
>         draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and
>         COMMENT)
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=utf-8
>
> On Fri, Feb 28, 2020 at 03:44:05PM +0100, Torsten Lodderstedt wrote:
> > Hi Ben,
> >
> > > On 25. Feb 2020, at 23:52, Benjamin Kaduk via Datatracker <
> [email-masked]> wrote:
> > >
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-oauth-jwt-introspection-response-08: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to all
> > > email addresses included in the To and CC lines. (Feel free to cut this
> > > introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > >
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/
> > >
> > >
> > >
> >
> > This post focuses on clarifying your DISCUSS comments in order to get
> the process moving again.
> >
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> > >
> > > Thank you for the updates in the -08; they address the bulk of the
> > > substantive issues!  I have a few points remaining on the -08 text but
> I
> > > think there are more localized issues to resolve.
> > >
> > > Can IANA please confirm that the new allocations in the -08 have
> > > received appropriate Expert (e.g., media type) review?  I see some
> > > updates in the datatracker history relating to the -08 but nothing in
> > > the email archives.
> > >
> > > It looks like we need to register 'active' as a JWT claim?
> >
> > That?s correct. Will add this.
> >
> > >
> > > I don't think the new semantics for "jti" in the introspection response
> > > are compatible with the RFC 7519 definition.  Specifically, we say that
> > > "jti" will be tied to the input access token, but 7519 says that "jti"
> > > has to change when the contents of the JWT change ("MUST be assigned in
> > > a manner that ensures that there is a negligible probability that the
> > > same value will be accidentally assigned to a different data object"),
> > > and we admit at least the possibility of "active" and "iat" changing.
> >
> > I think the key word is ?accidentally?. This spec causes the AS to
> purposefully issue JWTs with the same ?jti? in order to allow replay
> detection with respect to the introspected access token. ?iat? is changed
> in order to give the RS an indication and proof when the introspection
> response was minted by the AS.
>
> I think "accidentally" is just there to emphasize that there's a risk of
> accidental collision when using a random string as an identifier, since "of
> course you wouldn't deliberately reuse a token identifier".  This stance
> seems to supported by "[t]he 'jti' (JWT ID) claim provides a unique
> identifier for the JWT".  It's really hard for me to read that sentence as
> allowing the use of a single identifier for two different JWT values, since
> it then ceases to be a *unique* identifier.
>
> I seem to have forgotten how this replay detection is supposed to work;
> would you mind giving me a pointer and/or refresher?
>
> >
> > ?Active" does not really change, since the introspection response of an
> inactive token is empty except the ?active? element.
>
> I mean, the token artifact still changes.  What am I supposed to interpret
> "the JWT" as meaning if not the actual encoded artifact?
>
> > So I don?t see issues regarding RFC 7519.
> >
> > >
> > > Section 5 says that:
> > >
> > >   If the access token is considered active, it MUST contain the claims
> > >   "iss" and "aud" in order to prevent misuse of the JWT as an ID or
> > >   access token (see Section 8.1).
> > >
> > > But I don't think the predicate is correct -- misuse is still possible
> > > by services that do not check the "active" claim's value.  Shouldn't
> the
> > > "iss"+"aud" requirements be unconditional?
> >
> > Introspection responses for inactive tokens won?t contain any data
> except ?active?:false. I don?t see how they could be misused and therefore
> think the text is ok.
>
> -Ben
> > Please let me know whether you agree with my statements. I would then
> quickly publish a new revision (including changes to address your comments).
> >
> > best regards,
> > Torsten.
> >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> > >
> > > [New comments on the added text in the diff from -07 to -08.]
> > >
> > > Section 3
> > >
> > >   To support encrypted token introspection response JWTs, the
> > >   authorization server MUST also be provided with the respective
> > >   resource server encryption keys and algorithms.
> > >
> > > IIRC, based on some list discussion this text was going to be tweaked
> to
> > > avoid implying that JWE is mandatory.  (Unfortunately, this is the
> > > thread that evolved into "client certs and TLS Terminating Reverse
> > > Proxies", so it's hard to be sure whether I saw any other followups.)
> > >
> > >   The AS MUST restrict the use of client credentials by a RS to the
> > >   calls it requires, e.g. the AS MAY restrict such a client to call the
> > >   token introspection endpoint only.  How the AS implements this
> > >   restriction is beyond the scope of this specification.
> > >
> > > This should probably be clarified a bit more, in the context of "client
> > > credentials tend to be used by privileged, fixed endpoints, and the
> > > default may just be to allow them all access to all endpoints".  Right
> > > now it's not clear what's being restricted (and who "it" is that
> > > requires calls)
> > >
> > > Section 5
> > >
> > >   This specification registers the "application/token-
> > >   introspection+jwt" media type, which is used as value of the "typ"
> > >   header parameter of the JWT to indicate that the payload is a token
> > >   introspection response.
> > >
> > > Do we also want to note that checking 'jti' is not mandatory and so
> this
> > > does not necessarily provide full protection?  (I guess Section 8.1
> > > covers this in more detail.)
> > >
> > >   The value of the "aud" claims MUST identify the resource server
> > >   receiving the token introspection response.
> > >
> > > We may want to dig into this a bit more: should there be any
> > > relationship between this "aud" value and the "client_id" that an RS
> > > might be using (as obtained from dynamic registration)?
> > > Does this value need to be different from the audience that is used in
> > > access tokens for which this RS is the audience?  (Should it be the
> > > same?)  My instincts lean towards "different" but I would like broader
> > > input.
> > >
> > >   exp     The "exp" claim indicates when the access token passed in the
> > >           introspection request will expire.
> > >
> > > On the face of it this seems divergent from RFC 7519's "the expiration
> > > time on or after which the JWT MUST NOT be accepted for processing",
> > > though upon further examination the distinction is not quite so large.
> > > That is, it's in effect saying that the introspection response should
> > > not be accepted for processing after the base token has expired, which
> > > usually makes sense.  There is a bit of a complication, though, in that
> > > the "active" claim implies that we might still have RSes that plan to
> > > use the introspection response after the "exp" date has passed, which
> > > sounds a lot like a DISCUSS-level internal inconsistency.
> > >
> > >   If possible, the AS MUST narrow down the "scope" value to the scopes
> > >   relevant to the particular RS.
> > >
> > > This sounds kind of like a "SHOULD"...
> > >
> > >   The example response header contains the following JSON document:
> > >
> > > I think this is the JOSE header in the HTTP response (body), not the
> > > (HTTP) response header.
> > >
> > > Section 8.1
> > >
> > >   As an alternative approach, such an attack can be prevented like any
> > >   other token substitution attack by restricting the audience of the
> > >
> > > I'd suggest avoiding describing these as "alternatives"; they seem more
> > > like complementary approaches as part of a defense-in-depth solution
> > > (especially since we are basically mandating both of them).
> > >
> > >   "aud" value set to the resource server's identifier.  Any recipient
> > >   of an JWT MUST check these values in order to detect substitution
> > >   attacks.
> > >
> > > This "MUST" might be out of place -- this is a requirement from RFC
> > > 7519, and not an attempt by this document to make new requirements on
> > > the behavior of all JWT consumers (if it was, that would be a DISCUSS
> > > point!).
> > >
> > >   Resource servers MUST additionally apply the countermeasures against
> > >   replay as described in [I-D.ietf-oauth-security-topics], section 3.2.
> > >
> > > In a similar vein, which set of resources servers is this normative
> > > "MUST" intended to be binding upon?
> > >
> > > Section 9
> > >
> > >   In any case, the AS MUST ensure that the scope of the legal basis is
> > >   enforced throughout the whole process.  The AS MUST retain the scope
> > >   of the legal basis with the access token, e.g. in the scope value,
> > >   and the AS MUST determine the data a resource server is allowed to
> > >   receive based on the resource server's identity and suitable token
> > >   data, e.g. the scope value.
> > >
> > > I suspect I'm just being dense, but could you walk me through how the
> > > access token "scope" value can encode the legal basis for data
> transfer?
> > >
> > >
> > >
> >
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 1 Mar 2020 20:38:45 -0700
> From: David Waite <[email-masked]>
> To: Andrii Deinega <[email-masked]>
> Cc: Bill Jung <bjung=[email-masked]>,
>         [email-masked]
> Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 :
>         Refresh token?
> Message-ID:
>         <[email-masked]>
> Content-Type: text/plain;       charset=us-ascii
>
> I would expect the AS to invalidate the refresh token in this case, which
> would not require a refresh token mode nor necessarily any signaling back
> to the resource.
>
> -DW
>
> > On Mar 1, 2020, at 12:12 AM, Andrii Deinega <[email-masked]>
> wrote:
> >
> > Hello Bill,
> >
> > I'm just thinking out loud about possible scenarios for a protected
> > resource here... It may decide to revoke a refresh token if a client
> > application tried to use it instead of an access token when the
> > protected resource is paranoid about security. In order to do that an
> > introspection response should include a non-standard parameter which
> > indicates that the requested token is refresh_token.
> >
> > A user of the introspection endpoint should rely only on a value of
> > the active parameter (which is a boolean indicator) of the endpoint
> > response. This applies to both types of tokens. Note, the expiration
> > date, as well as other parameters, are defined as optional in the
> > specification. Both token types can be revoked before the expiration
> > date comes even if this parameter is presented as part of the
> > response. In my opinion, there are a number of reasons why this check
> > (for a refresh token) can be useful on the client application side.
> >
> > --
> > Regards,
> > Andrii
> >
> >
> > On Fri, Feb 28, 2020 at 1:59 AM Bill Jung
> > <bjung=[email-masked]> wrote:
> >>
> >> Hello, hopefully I am using the right email address.
> >>
> >> Simply put, can this spec be enhanced to clarify "Who can use the
> introspection endpoint for a refresh token? A resource provider or a client
> app or both?"
> >>
> >> RFC7662 clearly mentions that the user of introspection endpoint is a
> 'protected resource' and that makes sense for an access token. If we allow
> this to client apps, it'll give unnecessary token information to them.
> >> However, the spec also mentions that refresh tokens can also be used
> against the endpoint.
> >> In case of refresh tokens, user of the endpoint should be a client app
> because refresh tokens are used by clients to get another access token.
> (Cannot imagine how/why a resource server would introspect a refresh token)
> >>
> >> Is it correct to assume that the endpoint should be allowed to client
> apps if they want to examine refresh token's expiry time? Then the RFC
> should clearly mention it.
> >>
> >> Thanks in advance.
> >>
> >> <Details from the spec>
> >> In https://tools.ietf.org/html/rfc7662
> >> In '1.  Introduction' section says,
> >> "This specification defines a protocol that allows authorized
> >> protected resources to query the authorization server to determine
> >> the set of metadata for a given token that was presented to them by
> >> an OAuth 2.0 client."
> >> Above makes clear that user of the endpoint is a "protected resource".
> >>
> >> And under 'token' in '2.1.  Introspection Request' section says,
> >> "For refresh tokens,
> >> this is the "refresh_token" value returned from the token endpoint
> >> as defined in OAuth 2.0 [RFC6749], Section 5.1."
> >> So looks like a refresh token is allowed for this endpoint.
> >>
> >>
> >> Bill Jung
> >> Manager, Response Engineering
> >> [email-masked]
> >> w: +1 604.697.7037
> >> Connect with us:
> >>
> >> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you._______________________________________________
> >> OAuth mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 1 Mar 2020 21:11:40 -0800
> From: Andrii Deinega <[email-masked]>
> To: David Waite <[email-masked]>
> Cc: Bill Jung <bjung=[email-masked]>,
>         [email-masked]
> Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 :
>         Refresh token?
> Message-ID:
>         <CALkShct=sYSq-HoG=yMiV2BqT8+F=
> [email-masked]>
> Content-Type: text/plain; charset="UTF-8"
>
> How would the authorization server know who actually uses the
> introspection endpoint assuming that a protected resource and a client
> application use the same credentials (client_id and client_secret)?
>
> Regards,
> Andrii
>
> On Sun, Mar 1, 2020 at 7:38 PM David Waite <[email-masked]>
> wrote:
> >
> > I would expect the AS to invalidate the refresh token in this case,
> which would not require a refresh token mode nor necessarily any signaling
> back to the resource.
> >
> > -DW
> >
> > > On Mar 1, 2020, at 12:12 AM, Andrii Deinega <[email-masked]>
> wrote:
> > >
> > > Hello Bill,
> > >
> > > I'm just thinking out loud about possible scenarios for a protected
> > > resource here... It may decide to revoke a refresh token if a client
> > > application tried to use it instead of an access token when the
> > > protected resource is paranoid about security. In order to do that an
> > > introspection response should include a non-standard parameter which
> > > indicates that the requested token is refresh_token.
> > >
> > > A user of the introspection endpoint should rely only on a value of
> > > the active parameter (which is a boolean indicator) of the endpoint
> > > response. This applies to both types of tokens. Note, the expiration
> > > date, as well as other parameters, are defined as optional in the
> > > specification. Both token types can be revoked before the expiration
> > > date comes even if this parameter is presented as part of the
> > > response. In my opinion, there are a number of reasons why this check
> > > (for a refresh token) can be useful on the client application side.
> > >
> > > --
> > > Regards,
> > > Andrii
> > >
> > >
> > > On Fri, Feb 28, 2020 at 1:59 AM Bill Jung
> > > <bjung=[email-masked]> wrote:
> > >>
> > >> Hello, hopefully I am using the right email address.
> > >>
> > >> Simply put, can this spec be enhanced to clarify "Who can use the
> introspection endpoint for a refresh token? A resource provider or a client
> app or both?"
> > >>
> > >> RFC7662 clearly mentions that the user of introspection endpoint is a
> 'protected resource' and that makes sense for an access token. If we allow
> this to client apps, it'll give unnecessary token information to them.
> > >> However, the spec also mentions that refresh tokens can also be used
> against the endpoint.
> > >> In case of refresh tokens, user of the endpoint should be a client
> app because refresh tokens are used by clients to get another access token.
> (Cannot imagine how/why a resource server would introspect a refresh token)
> > >>
> > >> Is it correct to assume that the endpoint should be allowed to client
> apps if they want to examine refresh token's expiry time? Then the RFC
> should clearly mention it.
> > >>
> > >> Thanks in advance.
> > >>
> > >> <Details from the spec>
> > >> In https://tools.ietf.org/html/rfc7662
> > >> In '1.  Introduction' section says,
> > >> "This specification defines a protocol that allows authorized
> > >> protected resources to query the authorization server to determine
> > >> the set of metadata for a given token that was presented to them by
> > >> an OAuth 2.0 client."
> > >> Above makes clear that user of the endpoint is a "protected resource".
> > >>
> > >> And under 'token' in '2.1.  Introspection Request' section says,
> > >> "For refresh tokens,
> > >> this is the "refresh_token" value returned from the token endpoint
> > >> as defined in OAuth 2.0 [RFC6749], Section 5.1."
> > >> So looks like a refresh token is allowed for this endpoint.
> > >>
> > >>
> > >> Bill Jung
> > >> Manager, Response Engineering
> > >> [email-masked]
> > >> w: +1 604.697.7037
> > >> Connect with us:
> > >>
> > >> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you._______________________________________________
> > >> OAuth mailing list
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 1 Mar 2020 22:33:22 -0700
> From: David Waite <[email-masked]>
> To: Andrii Deinega <[email-masked]>
> Cc: Bill Jung <bjung=[email-masked]>,
>         [email-masked]
> Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 :
>         Refresh token?
> Message-ID:
>         <[email-masked]>
> Content-Type: text/plain;       charset=us-ascii
>
> On Mar 1, 2020, at 10:11 PM, Andrii Deinega <[email-masked]>
> wrote:
> >
> > How would the authorization server know who actually uses the
> > introspection endpoint assuming that a protected resource and a client
> > application use the same credentials (client_id and client_secret)?
>
> In the external context, you have a client accessing a protected resource
> with an access token. The client should treat the token as opaque, and
> RFC7662 makes no allowances for that client to introspect its tokens.
>
> If you control both the client and protected resource, you may decide to
> short-cut and have them share credentials. However, the client logic still
> should never be introspecting the tokens.
>
> The security considerations also say that you must prove the
> authentication of the protected resource, which I have interpreted to mean
> that access tokens used to authorize the call to the introspection endpoint
> must be issued to a confidential client - public clients cannot protect
> credentials to perform an authentication. You want to limit introspection
> to prevent denial of service and probing attacks, and to limit the amount
> of information on viable attacks conveyed if someone steals a token.
>
> -DW
>
> >
> > Regards,
> > Andrii
> >
> > On Sun, Mar 1, 2020 at 7:38 PM David Waite <[email-masked]>
> wrote:
> >>
> >> I would expect the AS to invalidate the refresh token in this case,
> which would not require a refresh token mode nor necessarily any signaling
> back to the resource.
> >>
> >> -DW
> >>
> >>> On Mar 1, 2020, at 12:12 AM, Andrii Deinega <[email-masked]>
> wrote:
> >>>
> >>> Hello Bill,
> >>>
> >>> I'm just thinking out loud about possible scenarios for a protected
> >>> resource here... It may decide to revoke a refresh token if a client
> >>> application tried to use it instead of an access token when the
> >>> protected resource is paranoid about security. In order to do that an
> >>> introspection response should include a non-standard parameter which
> >>> indicates that the requested token is refresh_token.
> >>>
> >>> A user of the introspection endpoint should rely only on a value of
> >>> the active parameter (which is a boolean indicator) of the endpoint
> >>> response. This applies to both types of tokens. Note, the expiration
> >>> date, as well as other parameters, are defined as optional in the
> >>> specification. Both token types can be revoked before the expiration
> >>> date comes even if this parameter is presented as part of the
> >>> response. In my opinion, there are a number of reasons why this check
> >>> (for a refresh token) can be useful on the client application side.
> >>>
> >>> --
> >>> Regards,
> >>> Andrii
> >>>
> >>>
> >>> On Fri, Feb 28, 2020 at 1:59 AM Bill Jung
> >>> <bjung=[email-masked]> wrote:
> >>>>
> >>>> Hello, hopefully I am using the right email address.
> >>>>
> >>>> Simply put, can this spec be enhanced to clarify "Who can use the
> introspection endpoint for a refresh token? A resource provider or a client
> app or both?"
> >>>>
> >>>> RFC7662 clearly mentions that the user of introspection endpoint is a
> 'protected resource' and that makes sense for an access token. If we allow
> this to client apps, it'll give unnecessary token information to them.
> >>>> However, the spec also mentions that refresh tokens can also be used
> against the endpoint.
> >>>> In case of refresh tokens, user of the endpoint should be a client
> app because refresh tokens are used by clients to get another access token.
> (Cannot imagine how/why a resource server would introspect a refresh token)
> >>>>
> >>>> Is it correct to assume that the endpoint should be allowed to client
> apps if they want to examine refresh token's expiry time? Then the RFC
> should clearly mention it.
> >>>>
> >>>> Thanks in advance.
> >>>>
> >>>> <Details from the spec>
> >>>> In https://tools.ietf.org/html/rfc7662
> >>>> In '1.  Introduction' section says,
> >>>> "This specification defines a protocol that allows authorized
> >>>> protected resources to query the authorization server to determine
> >>>> the set of metadata for a given token that was presented to them by
> >>>> an OAuth 2.0 client."
> >>>> Above makes clear that user of the endpoint is a "protected resource".
> >>>>
> >>>> And under 'token' in '2.1.  Introspection Request' section says,
> >>>> "For refresh tokens,
> >>>> this is the "refresh_token" value returned from the token endpoint
> >>>> as defined in OAuth 2.0 [RFC6749], Section 5.1."
> >>>> So looks like a refresh token is allowed for this endpoint.
> >>>>
> >>>>
> >>>> Bill Jung
> >>>> Manager, Response Engineering
> >>>> [email-masked]
> >>>> w: +1 604.697.7037
> >>>> Connect with us:
> >>>>
> >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you._______________________________________________
> >>>> OAuth mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 137, Issue 4
> *************************************
>