[OAUTH-WG] (no subject)

[Rebecca Warren]

Sent from Yahoo Mail for iPhone
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Ahmad Saferi Mat Said]

Ya. to be continued.
Just their website got protection by cookies.you know sometime it's not
easy to follow very high level protection.ya I m agree good to prevent
phishing and all fraud activities but sometimes it's make consumers
difficult.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Pol Newman]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[ABDÜLKADİR ÖZBUDAK]

ABDULKADİR ÖZBUDAK
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Hector Zepeda]

Downloaded and install
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Rebecca Warren]

Canary Mail
You've received a secure email
rgchas...@gmail.com has sent you a secure email via Canary Mail.

Read Secure Email 
(https://secure.canarymail.io/read?obj_id=b71ac538-ffa1-471b-8e75-6ba7deaa61b7_key=cUxhSlh6eWxNd1JROFBta1FYK3pVdz09_id=b71ac538-ffa1-471b-8e75-6ba7deaa61b7)

If you expect to correspond often with rgchas...@gmail.com, we recommend you 
download Canary Mail for free.

Download Canary (https://canarymail.io)

Privacy (https://canarymail.io/privacy.html) | Terms 
(https://canarymail.io/terms.html) | Docs (https://help.canarymail.io/) | 
Support (https://canarymail.zendesk.com/hc/en-us/requests/new)

Copyright © 2021 Canary Mail, All rights reserved.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Hector Zepeda]

Need this downloaded and install please
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Hector Zepeda]

Need this downloaded and install
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Hector Zepeda]

Need this downloaded
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Hector Zepeda]

Need this downloaded
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Rebecca Warren]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Rebecca Warren]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Rebecca Warren]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Rebecca Warren]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[ابو احمد الجادر]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Thandi Simbiwi]

  OnlineBankingDownload - Copy.pdf




TSimbiwi
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Thandi Simbiwi]

  CannedResponseDraft




TSimbiwi
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[MARIA CORAZON D.C BONACUA]

Confirmed
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Jospeter Murithi]

Ok
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Al Qutub Jewellers]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Paul Cabatuan]

paulcabatuan...@gmail.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Paul Cabatuan]

My acc
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Brian Barnett]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Maged Derar]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[yousef abusame]

Hi
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Heather LaDue]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Heather LaDue]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Ryan Acosta]

Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Ryan Acosta]

Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Ryan Acosta]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[เมฆ เอง]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[KAMPANAT THUMWONG]

KAMPANAT THUMWONG___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Multi-Subject JWT draft

[Rifaat Shekh-Yusef]

Thanks for the detailed feedback, Warren!

Yes, auditing is the obvious benefit that is one of the motivations for
this work, but I agree that it should be explicitly stated.

But, it is not limited to auditing. For example, in the telephony call
redirection case described in section 2.2.1, information from the nested
JWT is used in real-time and displayed to the user. When A calls B, and the
call is redirected to C, and when C receives the redirected call from A, C
will be able to tell that it is a redirected call because the details of
the original call will be displayed on the C's device in real time.

Regarding authorization: think about the parents' case again, and let's
assume that both parents can access the child's health records, but only
one of them can order medications. In this case, the details of the parent
are important and needed to make authorization decisions.

Regarding the multiple signatories use case: can you elaborate more on the
use case? The proposed solution in this document includes more than one JWT
including the JWT signatures. What's missing to enable this use case?

Regards,
 Rifaat






On Wed, Jun 15, 2022 at 4:18 AM Warren Parad  wrote:

> Okay, so I'm definitely missing the value. We want to make sure *user A
> is authorized to access user B's data* in a *resource server RS*. Either:
>
>1. The *resource server RS* needs to have a priori knowledge *that
>user A is allowed to access user B's data*
>2. Or user A needs to a have a token that contains user B as the
>subject
>
> In (1) we don't need to add any additional handling, this is the current
> path where authorization is being handled directly by the resource server.
> So let's take a look at (2). Is the AS required to ensure that the subject
> of the authorization is actually allowed to access user B's data?
>
>- In the case that the AS allows any user X to nest user B, then the
>resource server RS needs to *check that user A is allowed to access
>user B's data*. But this is already (1). So this solution doesn't
>offer any value. And further we would be opening up a pit failure creating
>tokens with any subject and only restricting them based on a new claim
>which not everyone will understand/process correctly.
>- So let's assume that the AS already knows and validates whether *user
>A is allowed to access user B's data* (suspect, since the AS likely
>doesn't include such granular RS access control understanding, but let's
>gloss over this) The nested claim in the token doesn't have any value to
>the resource server RS, because it doesn't know whether user A is allowed
>to access that data or not, it knows that the subject is B and B is allowed
>to access that data, and that's all it should care about. Since it
>delegated the decision to the AS and the AS knows, *then a token with
>subject B must be allowed to access user B's data, irrespective of the data
>in the nested claim*. Therefore, it doesn't provide any concrete value
>for authorization, and using that nested subject assuming it has meaning
>would contradict what the AS means. And further not every AS will follow
>this, opening another pit of failure.
>
> But does it provide any value? *Definitely*. Services can log and record
> the use of these authorization tokens in a resource first-class auditing
> approach. When asked "who accessed this data" The answer should be *user
> A* even though the subject of the token is *user B. *
>
> Which means, while not outlined in the draft, the conclusion is we are
> adding this functionality to *improve audit trails and NOT for
> authorization*. If we agree on that, then we can focus on improving how
> we expose this data. In that case, we might call this *Chained JWTs,* 
> *Rescoping
> JWTs, *or even potentially *JWT delegation audit trail*. And as long as
> we make it clear that this should never be used for authorization, we avoid
> the pit of failures I've mentioned above.
>
> And here's the third pitfall, it's frequently brought up about privacy,
> potentially the last thing that resource owners want is that more details
> about them are included into the access token being passed to resource
> servers which aren't necessary for the authorization itself. For instance
> adding the audit trail, may encourage AS to introduce personal
> information into this object based on where the user originated from
> enabling clients to abuse this information. I subscribe to the Resource
> Owner RO only wanting to expose the relevant information for an AS to tell
> a resource server if it should grant access and nothing more. (This of
> course is from the AS' perspective only, nothing here limits further
> decisions the RS can/should take based on its own context).
>
> Limiting the scope to *audit trails *would be a great option in general,
> except that we don't solve multi-party authorization. For instance, it is
> common, especially in 

Re: [OAUTH-WG] Multi-Subject JWT draft

[Warren Parad]

Okay, so I'm definitely missing the value. We want to make sure *user A is
authorized to access user B's data* in a *resource server RS*. Either:

   1. The *resource server RS* needs to have a priori knowledge *that user
   A is allowed to access user B's data*
   2. Or user A needs to a have a token that contains user B as the subject

In (1) we don't need to add any additional handling, this is the current
path where authorization is being handled directly by the resource server.
So let's take a look at (2). Is the AS required to ensure that the subject
of the authorization is actually allowed to access user B's data?

   - In the case that the AS allows any user X to nest user B, then the
   resource server RS needs to *check that user A is allowed to access user
   B's data*. But this is already (1). So this solution doesn't offer any
   value. And further we would be opening up a pit failure creating tokens
   with any subject and only restricting them based on a new claim which not
   everyone will understand/process correctly.
   - So let's assume that the AS already knows and validates whether *user
   A is allowed to access user B's data* (suspect, since the AS likely
   doesn't include such granular RS access control understanding, but let's
   gloss over this) The nested claim in the token doesn't have any value to
   the resource server RS, because it doesn't know whether user A is allowed
   to access that data or not, it knows that the subject is B and B is allowed
   to access that data, and that's all it should care about. Since it
   delegated the decision to the AS and the AS knows, *then a token with
   subject B must be allowed to access user B's data, irrespective of the data
   in the nested claim*. Therefore, it doesn't provide any concrete value
   for authorization, and using that nested subject assuming it has meaning
   would contradict what the AS means. And further not every AS will follow
   this, opening another pit of failure.

But does it provide any value? *Definitely*. Services can log and record
the use of these authorization tokens in a resource first-class auditing
approach. When asked "who accessed this data" The answer should be
*user A* even
though the subject of the token is *user B. *

Which means, while not outlined in the draft, the conclusion is we are
adding this functionality to *improve audit trails and NOT for
authorization*. If we agree on that, then we can focus on improving how we
expose this data. In that case, we might call this *Chained JWTs,* *Rescoping
JWTs, *or even potentially *JWT delegation audit trail*. And as long as we
make it clear that this should never be used for authorization, we avoid
the pit of failures I've mentioned above.

And here's the third pitfall, it's frequently brought up about privacy,
potentially the last thing that resource owners want is that more details
about them are included into the access token being passed to resource
servers which aren't necessary for the authorization itself. For instance
adding the audit trail, may encourage AS to introduce personal
information into this object based on where the user originated from
enabling clients to abuse this information. I subscribe to the Resource
Owner RO only wanting to expose the relevant information for an AS to tell
a resource server if it should grant access and nothing more. (This of
course is from the AS' perspective only, nothing here limits further
decisions the RS can/should take based on its own context).

Limiting the scope to *audit trails *would be a great option in general,
except that we don't solve multi-party authorization. For instance, it is
common, especially in the crypto space, to need multiple signatories before
enabling access. And perhaps we are taking some inspiration from that, the
trouble is here, we would need the JWT to contain both (all) signatures not
just the audit trail to be of value.

So I would recommend we scope the draft to either solve *multi-party*
problems (which is what is actually hinted to me by *multi-subject*) OR to
add an *audit trail* to JWTs.

On Tue, Jun 14, 2022 at 9:47 PM Rifaat Shekh-Yusef 
wrote:

> Yes to both questions.
>
> On Tue, Jun 14, 2022 at 2:22 PM Warren Parad  wrote:
>
>> Is it helpful to challenge this implementation? (and is this email thread
>> the right place to do it?)
>>
>> On Tue, Jun 14, 2022 at 5:27 PM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> It is a Nested JWT with at least *two related subjects*, one in the
>>> enclosed JWT and another in the enclosing JWT.
>>> Having said that, I do not have a strong opinion on the name and we
>>> could potentially change it to a name that more accurately reflects the
>>> scope of the document, if needed.
>>>
>>> The justification for this is that in a number of use cases there is a
>>> need for both JWTs to be present, to allow the resource server to apply
>>> authorization based on who requested the access to the resource and on
>>> 

Re: [OAUTH-WG] Multi-Subject JWT draft

[Rifaat Shekh-Yusef]

Yes to both questions.

On Tue, Jun 14, 2022 at 2:22 PM Warren Parad  wrote:

> Is it helpful to challenge this implementation? (and is this email thread
> the right place to do it?)
>
> On Tue, Jun 14, 2022 at 5:27 PM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> It is a Nested JWT with at least *two related subjects*, one in the
>> enclosed JWT and another in the enclosing JWT.
>> Having said that, I do not have a strong opinion on the name and we could
>> potentially change it to a name that more accurately reflects the scope of
>> the document, if needed.
>>
>> The justification for this is that in a number of use cases there is a
>> need for both JWTs to be present, to allow the resource server to apply
>> authorization based on who requested the access to the resource and on
>> behalf of who is the request. For example, a parent ordering medication for
>> their child. There are other use cases described in the document.
>>
>> Regards,
>>  Rifaat
>>
>>
>>
>>
>> On Tue, Jun 14, 2022 at 11:09 AM Warren Parad  wrote:
>>
>>> After reading the draft I also have some concerns. This still isn't
>>> multi-subject, right? As there is only one subject, there just happens to
>>> be a new claim with additional information in it. I'm still behind on the
>>> justification for creating this, as at first glance, either the user got an
>>> access token on behalf of the other user to access their resources or they
>>> are impersonating the other user. So I'm not totally sure I understand the
>>> immediate value/problem statement, but that could be discussed separately.
>>>
>>> There's still only one subject, right? I would recommend that
>>> `multi-subject` be removed from the draft name. For instance, why not:
>>>
>>>- Nested Subject JWT Claims
>>>
>>> Or maybe we want to talk about the value:
>>>
>>>- Delegating Authorization using Nested Subject Claims in JWTs
>>>
>>>
>>>
>>> On Tue, Jun 14, 2022 at 5:05 PM Rifaat Shekh-Yusef <
>>> rifaat.s.i...@gmail.com> wrote:
>>>
 Hi Dick,

 The initial scope of the document was very limited to extending the
 existing Nested JWT to allow the enclosing JWT to have its own claims.
 Since then, it was clear that there are many use cases that need such a
 mechanism that requires more than just a simple nesting of JWTs. That's the
 reason I changed the name, to reflect the larger scope of this document.

 I do not mind changing the name, if it makes sense.
 Would changing the name to Multi-Subject Nested JWT help address your
 concern?

 Regards,
  Rifaat




 On Tue, Jun 14, 2022 at 10:46 AM Dick Hardt 
 wrote:

> Hi Rifaat
>
> I'm suspecting there was a conversation on changing the name to
> multi-subject JWT. Would you provide a pointer or short summary?
>
> I find the name concerning as I am looking at a very different concept
> that would also be considered a multi-subject JWT.
>
>
> My use case is where user accounts have been merged, and the issuer
> has multiple "sub" claims for the same user and would like to include all
> the values in the JWT to signal to the RP that the accounts have been
> merged.
>
> I was considering calling it "aka" and it would be an array of
> identifiers. "aka" => Also Known As
>
> /Dick
>
> On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> I have just submitted an updated version of the *Multi-Subject JWT*
>> draft (formerly known as Nested JWT) with more details.
>> I would appreciate any reviews and feedback on this version.
>> https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt
>>
>> Regards,
>>  Rifaat
>>
>> ___
>> 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 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Multi-Subject JWT draft

[Warren Parad]

Is it helpful to challenge this implementation? (and is this email thread
the right place to do it?)

On Tue, Jun 14, 2022 at 5:27 PM Rifaat Shekh-Yusef 
wrote:

> It is a Nested JWT with at least *two related subjects*, one in the
> enclosed JWT and another in the enclosing JWT.
> Having said that, I do not have a strong opinion on the name and we could
> potentially change it to a name that more accurately reflects the scope of
> the document, if needed.
>
> The justification for this is that in a number of use cases there is a
> need for both JWTs to be present, to allow the resource server to apply
> authorization based on who requested the access to the resource and on
> behalf of who is the request. For example, a parent ordering medication for
> their child. There are other use cases described in the document.
>
> Regards,
>  Rifaat
>
>
>
>
> On Tue, Jun 14, 2022 at 11:09 AM Warren Parad  wrote:
>
>> After reading the draft I also have some concerns. This still isn't
>> multi-subject, right? As there is only one subject, there just happens to
>> be a new claim with additional information in it. I'm still behind on the
>> justification for creating this, as at first glance, either the user got an
>> access token on behalf of the other user to access their resources or they
>> are impersonating the other user. So I'm not totally sure I understand the
>> immediate value/problem statement, but that could be discussed separately.
>>
>> There's still only one subject, right? I would recommend that
>> `multi-subject` be removed from the draft name. For instance, why not:
>>
>>- Nested Subject JWT Claims
>>
>> Or maybe we want to talk about the value:
>>
>>- Delegating Authorization using Nested Subject Claims in JWTs
>>
>>
>>
>> On Tue, Jun 14, 2022 at 5:05 PM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> Hi Dick,
>>>
>>> The initial scope of the document was very limited to extending the
>>> existing Nested JWT to allow the enclosing JWT to have its own claims.
>>> Since then, it was clear that there are many use cases that need such a
>>> mechanism that requires more than just a simple nesting of JWTs. That's the
>>> reason I changed the name, to reflect the larger scope of this document.
>>>
>>> I do not mind changing the name, if it makes sense.
>>> Would changing the name to Multi-Subject Nested JWT help address your
>>> concern?
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>>
>>>
>>> On Tue, Jun 14, 2022 at 10:46 AM Dick Hardt 
>>> wrote:
>>>
 Hi Rifaat

 I'm suspecting there was a conversation on changing the name to
 multi-subject JWT. Would you provide a pointer or short summary?

 I find the name concerning as I am looking at a very different concept
 that would also be considered a multi-subject JWT.


 My use case is where user accounts have been merged, and the issuer has
 multiple "sub" claims for the same user and would like to include all the
 values in the JWT to signal to the RP that the accounts have been merged.

 I was considering calling it "aka" and it would be an array of
 identifiers. "aka" => Also Known As

 /Dick

 On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef <
 rifaat.s.i...@gmail.com> wrote:

> I have just submitted an updated version of the *Multi-Subject JWT*
> draft (formerly known as Nested JWT) with more details.
> I would appreciate any reviews and feedback on this version.
> https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt
>
> Regards,
>  Rifaat
>
> ___
> 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 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Multi-Subject JWT draft

[Rifaat Shekh-Yusef]

It is a Nested JWT with at least *two related subjects*, one in the
enclosed JWT and another in the enclosing JWT.
Having said that, I do not have a strong opinion on the name and we could
potentially change it to a name that more accurately reflects the scope of
the document, if needed.

The justification for this is that in a number of use cases there is a need
for both JWTs to be present, to allow the resource server to apply
authorization based on who requested the access to the resource and on
behalf of who is the request. For example, a parent ordering medication for
their child. There are other use cases described in the document.

Regards,
 Rifaat




On Tue, Jun 14, 2022 at 11:09 AM Warren Parad  wrote:

> After reading the draft I also have some concerns. This still isn't
> multi-subject, right? As there is only one subject, there just happens to
> be a new claim with additional information in it. I'm still behind on the
> justification for creating this, as at first glance, either the user got an
> access token on behalf of the other user to access their resources or they
> are impersonating the other user. So I'm not totally sure I understand the
> immediate value/problem statement, but that could be discussed separately.
>
> There's still only one subject, right? I would recommend that
> `multi-subject` be removed from the draft name. For instance, why not:
>
>- Nested Subject JWT Claims
>
> Or maybe we want to talk about the value:
>
>- Delegating Authorization using Nested Subject Claims in JWTs
>
>
>
> On Tue, Jun 14, 2022 at 5:05 PM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> Hi Dick,
>>
>> The initial scope of the document was very limited to extending the
>> existing Nested JWT to allow the enclosing JWT to have its own claims.
>> Since then, it was clear that there are many use cases that need such a
>> mechanism that requires more than just a simple nesting of JWTs. That's the
>> reason I changed the name, to reflect the larger scope of this document.
>>
>> I do not mind changing the name, if it makes sense.
>> Would changing the name to Multi-Subject Nested JWT help address your
>> concern?
>>
>> Regards,
>>  Rifaat
>>
>>
>>
>>
>> On Tue, Jun 14, 2022 at 10:46 AM Dick Hardt  wrote:
>>
>>> Hi Rifaat
>>>
>>> I'm suspecting there was a conversation on changing the name to
>>> multi-subject JWT. Would you provide a pointer or short summary?
>>>
>>> I find the name concerning as I am looking at a very different concept
>>> that would also be considered a multi-subject JWT.
>>>
>>>
>>> My use case is where user accounts have been merged, and the issuer has
>>> multiple "sub" claims for the same user and would like to include all the
>>> values in the JWT to signal to the RP that the accounts have been merged.
>>>
>>> I was considering calling it "aka" and it would be an array of
>>> identifiers. "aka" => Also Known As
>>>
>>> /Dick
>>>
>>> On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef <
>>> rifaat.s.i...@gmail.com> wrote:
>>>
 I have just submitted an updated version of the *Multi-Subject JWT*
 draft (formerly known as Nested JWT) with more details.
 I would appreciate any reviews and feedback on this version.
 https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt

 Regards,
  Rifaat

 ___
 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 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Multi-Subject JWT draft

[Warren Parad]

After reading the draft I also have some concerns. This still isn't
multi-subject, right? As there is only one subject, there just happens to
be a new claim with additional information in it. I'm still behind on the
justification for creating this, as at first glance, either the user got an
access token on behalf of the other user to access their resources or they
are impersonating the other user. So I'm not totally sure I understand the
immediate value/problem statement, but that could be discussed separately.

There's still only one subject, right? I would recommend that
`multi-subject` be removed from the draft name. For instance, why not:

   - Nested Subject JWT Claims

Or maybe we want to talk about the value:

   - Delegating Authorization using Nested Subject Claims in JWTs



On Tue, Jun 14, 2022 at 5:05 PM Rifaat Shekh-Yusef 
wrote:

> Hi Dick,
>
> The initial scope of the document was very limited to extending the
> existing Nested JWT to allow the enclosing JWT to have its own claims.
> Since then, it was clear that there are many use cases that need such a
> mechanism that requires more than just a simple nesting of JWTs. That's the
> reason I changed the name, to reflect the larger scope of this document.
>
> I do not mind changing the name, if it makes sense.
> Would changing the name to Multi-Subject Nested JWT help address your
> concern?
>
> Regards,
>  Rifaat
>
>
>
>
> On Tue, Jun 14, 2022 at 10:46 AM Dick Hardt  wrote:
>
>> Hi Rifaat
>>
>> I'm suspecting there was a conversation on changing the name to
>> multi-subject JWT. Would you provide a pointer or short summary?
>>
>> I find the name concerning as I am looking at a very different concept
>> that would also be considered a multi-subject JWT.
>>
>>
>> My use case is where user accounts have been merged, and the issuer has
>> multiple "sub" claims for the same user and would like to include all the
>> values in the JWT to signal to the RP that the accounts have been merged.
>>
>> I was considering calling it "aka" and it would be an array of
>> identifiers. "aka" => Also Known As
>>
>> /Dick
>>
>> On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> I have just submitted an updated version of the *Multi-Subject JWT*
>>> draft (formerly known as Nested JWT) with more details.
>>> I would appreciate any reviews and feedback on this version.
>>> https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt
>>>
>>> Regards,
>>>  Rifaat
>>>
>>> ___
>>> 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 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Multi-Subject JWT draft

[Rifaat Shekh-Yusef]

Hi Dick,

The initial scope of the document was very limited to extending the
existing Nested JWT to allow the enclosing JWT to have its own claims.
Since then, it was clear that there are many use cases that need such a
mechanism that requires more than just a simple nesting of JWTs. That's the
reason I changed the name, to reflect the larger scope of this document.

I do not mind changing the name, if it makes sense.
Would changing the name to Multi-Subject Nested JWT help address your
concern?

Regards,
 Rifaat




On Tue, Jun 14, 2022 at 10:46 AM Dick Hardt  wrote:

> Hi Rifaat
>
> I'm suspecting there was a conversation on changing the name to
> multi-subject JWT. Would you provide a pointer or short summary?
>
> I find the name concerning as I am looking at a very different concept
> that would also be considered a multi-subject JWT.
>
>
> My use case is where user accounts have been merged, and the issuer has
> multiple "sub" claims for the same user and would like to include all the
> values in the JWT to signal to the RP that the accounts have been merged.
>
> I was considering calling it "aka" and it would be an array of
> identifiers. "aka" => Also Known As
>
> /Dick
>
> On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> I have just submitted an updated version of the *Multi-Subject JWT*
>> draft (formerly known as Nested JWT) with more details.
>> I would appreciate any reviews and feedback on this version.
>> https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt
>>
>> Regards,
>>  Rifaat
>>
>> ___
>> 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

Re: [OAUTH-WG] Multi-Subject JWT draft

[Dick Hardt]

Hi Rifaat

I'm suspecting there was a conversation on changing the name to
multi-subject JWT. Would you provide a pointer or short summary?

I find the name concerning as I am looking at a very different concept that
would also be considered a multi-subject JWT.


My use case is where user accounts have been merged, and the issuer has
multiple "sub" claims for the same user and would like to include all the
values in the JWT to signal to the RP that the accounts have been merged.

I was considering calling it "aka" and it would be an array of identifiers.
"aka" => Also Known As

/Dick

On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef 
wrote:

> I have just submitted an updated version of the *Multi-Subject JWT* draft
> (formerly known as Nested JWT) with more details.
> I would appreciate any reviews and feedback on this version.
> https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt
>
> Regards,
>  Rifaat
>
> ___
> 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-WG] Multi-Subject JWT draft

[Rifaat Shekh-Yusef]

I have just submitted an updated version of the *Multi-Subject JWT* draft
(formerly known as Nested JWT) with more details.
I would appreciate any reviews and feedback on this version.
https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt

Regards,
 Rifaat
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[เมฆ เอง]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[เมฆ เอง]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[เมฆ เอง]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[เมฆ เอง]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Brittney Boone]

Hi. I am new to this and really need some help. Is there some way to get
some guidance ?

Thank you
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (No Subject)

[Perrylyndon]

perrylynd...@protonmail.com___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Jesse Ronnie Strickland]

Sent from Yahoo for iPhone
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Seenimohamed Seenimohamedaudo]

72/112NethajiNager3thstreetTondriped Chennai TamilNadu post 600081 post
code 464

seenimohamed
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[remik lab]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Joshua N]

Check out xooa. See if that can be something. Xooa.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[TEDDY VETETO]

"Re:" is ok.)
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Rifaat Shekh-Yusef]

All,

Take a look at the following links for the April 19th interim meeting
minutes:
https://codimd.ietf.org/s/notes-ietf-interim-2021-oauth-06-oauth
https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-06-202104191200/

Thanks to *Heather Flanagan *for taking these notes.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Savage Hood]

"Re: Contents of OAuth digest..."
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Multi-Subject JWT (aka Nested JWT)

[Rifaat Shekh-Yusef]

I submitted a new version of the draft to reflect the focus on
Multi-Subject JWT:
https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/

I would appreciate any feedback on this.

Regards,
 Rifaat


On Thu, Feb 18, 2021 at 7:26 AM Rifaat Shekh-Yusef 
wrote:

> When I started working on the Nested JWT draft, I had a specific use case
> in mind (I no longer care about that initial use case).
> https://www.ietf.org/archive/id/draft-yusef-oauth-nested-jwt-03.txt
>
> I then dropped the ball on the Nested JWT draft, but every now and then I
> get some feedback, mainly offline, from different people about more use
> cases that clearly indicate that there is a need for a way to represent
> multiple subjects in one JWT.
>
> The following is a high level summary of these use cases:
>
>
>1.
>
>Primary subject with secondary authority subject
>
> A primary subject with a related secondary subject that has authority over
> the primary subject, e.g. Child/Parent, Pet/Owner.
>
> In this case, both JWTs would be issued by the same issuer.
>
>
>1.
>
>Delegation of authority
>
> A primary subject delegates authority over a resource to a secondary
> subject who acts on behalf of the primary subject.
>
> https://tools.ietf.org/html/rfc8693
>
> In this case, both JWTs would be issued by the same issuer.
>
>
>1.
>
>Multiple primary subjects
>
> Two primary related subjects e.g. a married couple
>
> https://www.w3.org/TR/vc-data-model/#credential-subject
>
> In this case, both JWTs would be issued by the same issuer.
>
>
>1.
>
>Replaced primary subject
>
> A primary subject becomes a secondary subject and replaced with a new
> primary subject.
>
> For example,
>
>-
>
>An original called number replaced with a retargeted number.
>
> https://tools.ietf.org/html/draft-ietf-stir-passport-divert-09
>
>
>-
>
>A number of network intermediaries that each become the primary
>subject when receiving a message from a previous network element.
>
> https://networkservicemesh.io/
>
> In this case, the original JWT would be issued by one issuer and included
> as a nested JWT, while the enclosing JWT would be issued by a new issuer
> that has manipulated the original received message.
>
>
>1.
>
>Supporting JWTs
>
> One primary JWT with supporting JWT
>
> https://github.com/martinpaljak/jose/blob/main/README.md
>
>
> *Question*:
> Is the WG interested in working on such a mechanism?
> If yes, are there any more use cases that need to be addressed?
> Are there use cases that require more than two subjects?
>
> Regards,
>  Rifaat (no hats)
>
>
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Halim Dimitry Halim]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Multi-Subject JWT (aka Nested JWT)

[Rifaat Shekh-Yusef]

When I started working on the Nested JWT draft, I had a specific use case
in mind (I no longer care about that initial use case).
https://www.ietf.org/archive/id/draft-yusef-oauth-nested-jwt-03.txt

I then dropped the ball on the Nested JWT draft, but every now and then I
get some feedback, mainly offline, from different people about more use
cases that clearly indicate that there is a need for a way to represent
multiple subjects in one JWT.

The following is a high level summary of these use cases:


   1.

   Primary subject with secondary authority subject

A primary subject with a related secondary subject that has authority over
the primary subject, e.g. Child/Parent, Pet/Owner.

In this case, both JWTs would be issued by the same issuer.


   1.

   Delegation of authority

A primary subject delegates authority over a resource to a secondary
subject who acts on behalf of the primary subject.

https://tools.ietf.org/html/rfc8693

In this case, both JWTs would be issued by the same issuer.


   1.

   Multiple primary subjects

Two primary related subjects e.g. a married couple

https://www.w3.org/TR/vc-data-model/#credential-subject

In this case, both JWTs would be issued by the same issuer.


   1.

   Replaced primary subject

A primary subject becomes a secondary subject and replaced with a new
primary subject.

For example,

   -

   An original called number replaced with a retargeted number.

https://tools.ietf.org/html/draft-ietf-stir-passport-divert-09


   -

   A number of network intermediaries that each become the primary subject
   when receiving a message from a previous network element.

https://networkservicemesh.io/

In this case, the original JWT would be issued by one issuer and included
as a nested JWT, while the enclosing JWT would be issued by a new issuer
that has manipulated the original received message.


   1.

   Supporting JWTs

One primary JWT with supporting JWT

https://github.com/martinpaljak/jose/blob/main/README.md


*Question*:
Is the WG interested in working on such a mechanism?
If yes, are there any more use cases that need to be addressed?
Are there use cases that require more than two subjects?

Regards,
 Rifaat (no hats)
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Joey Galvin]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[RFC ISE (Adrian Farrel)]

Hi OAuth,

The authors of draft-ideskog-assisted-token [1] have approached me
requesting that the draft be published as an Informational RFC in the
Independent Submission Stream [2].

The draft extends the OAuth 2.0 framework to include an additional
authorization flow for single page applications called the assisted token
flow. It is intended to enable OAuth clients that are written in scripting
languages (such as JavaScript) to request user authorization using a
simplified method. Communication leverages HTML's iframe element, child
windows, and the postMessage interface. This communication is done using
an additional endpoint, the assisted token endpoint.

It is clear to me that this work could be in scope for OAuth and I want to
be sure that both:
- there is no interest within the WG in pursuing this approach
- there is no perceived harm to existing OAuth work if this goes ahead

I'd appreciate any opinions.

Many thanks,
Adrian
-- 
Adrian Farrel (Independent Submissions Editor),
rfc-...@rfc-editor.org

[1] https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/
[2] https://www.rfc-editor.org/about/independent/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[الشيف النجار]

السلام عليكم 
مكن مساعدتي في ارجاع حسابي 

‫أُرسلت من الـ iPhone‬___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Kevin Powell]

Send permission
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Bunh Tha Chau]

Thanks
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] FW: Subject claim ... was : About draft-ietf-oauth-access-token-jwt-10

[Hannes Tschofenig]

FYI: Forwarding this email to the list so that we can continue the conversation 
here.

Below, I am trying to find out whether there is room for improvement on the 
text regarding the uniqueness of the “sub” claim.

Ciao
Hannes


From: Denis 
Sent: Thursday, September 24, 2020 12:29 PM
To: Hannes Tschofenig 
Cc: vittorio.berto...@auth0.com
Subject: Re: Subject claim ... was : [OAUTH-WG] About 
draft-ietf-oauth-access-token-jwt-10

Hi Hannes,

You apparently missed my second email from this morning where I said that the 
oauth mailing list was not copied whereas it should.
Hi Denis,

I am trying to understand the text written below since I believe the old and 
the new text actually say something different.

>  When the "sub" claim is scoped to be locally unique in the context of the 
> issuer, in the event of resource servers collusion, it can be used to 
> correlate principals.

When the "sub" claim is scoped to be locally unique in the context of the 
issuer then this does not automatically mean that two resource servers can find 
out that two subsequent requests are actually from the same principal.

I am sorry but it does mean this. The current (old) text is making 
interpretations of section 4.1.2 from RFC 7519 that are not in accordance with 
it.

This is a follow up of the "four flavours" I already mentioned that you were 
not able to understand.

I don't argue that assigning different values to identify the principal would 
be a bad thing, but unfortunately the "sub" attribute cannot be used for this.

The new text I propose is strictly sticking to the two "flavours" of the 
definition from RFC 7519 and hence cannot consider four flavours.

A globally unique identifier cannot be a one-time identifier. A good example of 
a globally unique identifier is an email address.

I hope this clarifies the issue.

Since at this time, the whole mailing list has been kept ignorant of the 
exchanges we had this morning, I would recommend
that you answer to the Comments 3 of my original email as if the exchanges we 
had this morning did not existed.

Denis


The old text explains how this works and says
“
Similarly, if a solution requires preventing a resource server from correlating 
the
   principal’s activity within the resource itself, the authorization server 
should assign different "sub" values for every JWT access
   token issued.
“

Your next text does not have that case anymore.

Even the use of a globally unique identifier does not allow correlation if you 
issue one-time identifiers and use the access tokens only with the 
audience-restricted resource servers.

I believe that the distinction between locally scoped to the issuer and 
globally scoped isn’t actually that relevant because even a locally scoped 
subject claim can easily be turned into a globally scoped one if you append the 
issuer identifier to it.

Am I missing something here?

Ciao
Hannes

From: Denis <mailto:denis.i...@free.fr>
Sent: Thursday, September 24, 2020 9:18 AM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; 
vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com>
Subject: Re: Subject claim ... was : [OAUTH-WG] About 
draft-ietf-oauth-access-token-jwt-10

Hello Hannes,

You have deleted the original text that I sent about Comment 3 and hence the 
thread has been broken.

I am proposing to change the following text in section 6 (Privacy 
Considerations):

  This profile mandates the presence of the "sub" claim in every JWT access 
token, making it possible for resource servers to rely on that
   information for correlating incoming requests with data stored  locally for 
the authenticated principal.  Although the ability to
   correlate requests might be required by design in many scenarios, there are 
scenarios where the authorization server might want to
   prevent correlation.  The "sub" claim should be populated by the 
authorization servers according to a privacy impact assessment.  For
   instance, if a solution requires preventing tracking principal activities 
across multiple resource servers, the authorization server
   should ensure that JWT access tokens meant for different resource servers 
have distinct "sub" values that cannot be correlated in the
   event of resource servers collusion.  Similarly, if a solution requires 
preventing a resource server from correlating the
   principal’s activity within the resource itself, the authorization server 
should assign different "sub" values for every JWT access
   token issued.  In turn, the client should obtain a new JWT access token for 
every call to the resource server, to ensure that the
   resource server receives different "sub" and "jti" values at every call, 
thus preventing correlation between distinct requests.

by the following text:

  This profile mandates the presence of the "sub&quo

Re: [OAUTH-WG] (no subject)

[Deepak Tiwari]

Remove my email

On Thu, Sep 10, 2020 at 5:58 AM Tricia Dalton 
wrote:

> 18b47345e3e8895f3662160c8819768222595852
> Remove my email
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 

Regards,

*Deepak Tiwari|* Software Engineer
Intigate Technologies Pvt. Ltd. | www.intigate.co.in
Ist Floor, A-119
Sector-63
Noida (U.P.) 201301
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Tricia Dalton]

18b47345e3e8895f3662160c8819768222595852
Remove my email
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[MŌHĀMĀD ĀLĪF ĪMRĀN BĪN MŪSTĀPHĀ]

Yes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Schlampa Schlampa]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Schlampa Schlampa]

https://adguard.com/de/versions/android/release.html?utm_source=android_medium=activity_about_campaign=versionhistory
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Schlampa Schlampa]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Schlampa Schlampa]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Vanessa Andor]

"Help"
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Mike Booth]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Wendy Irene Haas]

tls_client_auth_subject_dn An [RFC4514] string representation of the
expected subject distinguished name of the certificate, which the OAuth
client will use in mutual TLS authentication. tls_client_auth_san_dns A
string containing the value of an expected dNSName SAN entry in the
certificate, which the OAuth client will use in mutual TLS authentication.
tls_client_auth_san_uri A string containing the value of an expected
uniformResourceIdentifier SAN entry in the certificate, which the OAuth
client will use in mutual TLS authentication. tls_client_auth_san_ip A
string representation of an IP address in either dotted decimal notation
(for IPv4) or colon-delimited hexadecimal (for IPv6, as defined in
[RFC4291] section 2.2) that is expected to be present as an iPAddress SAN
entry in the certificate, which the OAuth client will use in mutual TLS
authentication.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Владимир Кравчук]

вы мне все время присылаете пустые письма,смысл вашей рассылки?

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Chef Saroar]

Hi
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Chef Saroar]

Hi
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Eysz 7Words]

  
  


  
  
  


e...@ietf.org


Dapatkan Outlook for iOS

  
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Петров Юрий]

Отправлено из Почта для Windows 
10

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Woop Crabtree]

Sent from Email

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Владимир Кравчук]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Salahattin Subak]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Heng Puthireach]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] (no subject)

[Rifaat Shekh-Yusef]

Use the following link to subscribe:
https://www.ietf.org/mailman/listinfo/oauth

Regards,
 Rifaat


On Wednesday, August 2, 2017, Bone Bizz  wrote:

> Hello,  id like to join the mailing list for Android.  Thanks alot.
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Bone Bizz]

Hello,  id like to join the mailing list for Android.  Thanks alot.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Та Ч Классно]

--
Отправлено из Mail.Ru для Android___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[yan tan]

OAuth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Та Ч Классно]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Dred J]

 --   J Dred from  --
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Dred J]

 --   J Dred from  --
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[ronald comaling]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[วงศ์วริศ เธียรโชติทวีบุญ]

ส่งจาก Windows Phone ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[วงศ์วริศ เธียรโชติทวีบุญ]

ส่งจาก Windows Phone ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[วงศ์วริศ เธียรโชติทวีบุญ]

ส่งจาก Windows Phone ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[GHOST SPY]

ghostcharme...@gmail.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Panca Panca . blogspot . com]

 Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Panca Agus Ananda]

 Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Sarah Johansen]

Where. what,when

Sarah-E-Johansen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Sunil Pal]

---
Thanks And Warm Regards
Sunil Kumar Pal
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Maik Mahn]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Josh Wernicke]

Stop
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth