Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question

[Deepak Tiwari]

Please remove my email from the conversation

On Tue, Sep 22, 2020 at 7:39 AM Logan Widick  wrote:

> If I understand "The intent would be to present that information in the
> same way you would when querying a users/, encoded in claims" correctly,
> the "roles", "groups", and "entitlements" claims are the same types as the
> "roles", "groups", and "entitlements" attributes of the User resource
> schema (pages 24-25 of RFC 7643 for the text; pages 63-67 of RFC 7643 for
> the schema)? In the schema the attributes are all "complex" (object) type
> and "multivalued" (array of), although the text for some of these
> attributes has some "No vocabulary or syntax..." remarks.
>
> If that understanding is correct, it might be a good idea to replace the
> references to "RFC 7643", "Section 4.1.2 of RFC 7643", and "RFC 7643,
> Section 4.1.2" with something more specific like "the  attribute(s) of
> the User resource schema from Section 4.1.2 of RFC 7643".
>
> On Mon, Sep 21, 2020, 15:33 Brian Campbell 
> wrote:
>
>> At some point I'm going to be among the lucky few who will be asked to
>> review the JWT claims registration request. One of the criteria to consider
>> is "whether the registration description is clear" and Logan's questions
>> suggest that perhaps the descriptions of these claims are not sufficiently
>> clear. My assumption was that the claim value for "roles", "groups" and
>> "entitlements" was going to be an array of strings. Trying to validate my
>> assumption, I went looking at the text in
>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-2.2.3.1
>> and
>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-7.2
>> and followed the reference to
>> https://tools.ietf.org/html/rfc7643#section-4.1.2 and, honestly, it
>> wasn't particularly clear to me. Maybe it's my lack of familiarity with the
>> details of SCIM and the language of RFC 7643. But I think that, for the
>> sake of clarity and interoperability, some additional specificity is
>> needed.
>>
>> Side note: the "Section 2.2.2.1 of [[this specification]]" references in
>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-7.2.1
>> are problmatic (there is no such section in this document) and probably
>> should be to 2.2.3.1.
>>
>> On Fri, Sep 18, 2020 at 6:28 PM Vittorio Bertocci > 40auth0@dmarc.ietf.org> wrote:
>>
>>> Hi Logan,
>>>
>>> Thanks for the note.
>>>
>>> The intent would be to present that information in the same way you
>>> would when querying a users/, encoded in claims; hence groups would be
>>> a list of values representing  what groups the subject belongs to, rather
>>> than a list of full group definitions (with all the other members belonging
>>> to them, for example) which would go beyond the intended use of the
>>> information (supplying authorization information about the subject).
>>>
>>> I tried to keep the language high level as I didn’t want to duplicate
>>> SCIM guidance, or inadvertently narrow down the options products have to
>>> implement this.  If you think this is too vague, we can try to be more
>>> specific.
>>>
>>>
>>>
>>> *From: *OAuth  on behalf of Logan Widick <
>>> logan.wid...@gmail.com>
>>> *Date: *Wednesday, September 16, 2020 at 14:21
>>> *To: *"oauth@ietf.org" 
>>> *Subject: *[OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question
>>>
>>>
>>>
>>> I took a look at Section 2.2.3.1: Claims for Authorization Outside of
>>> Delegation Scenarios (
>>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-08#section-2.2.3.1)
>>> and I do not understand what exactly the formats of the "roles", "groups",
>>> and "entitlements" claims will be.
>>>
>>> Will the "roles" claim be an array of strings (role names, IDs, or
>>> links), an array of the "roles" objects from the SCIM User schema (pages
>>> 66-67 of RFC 7643), or something else?
>>>
>>> Will the "groups" claim be an array of strings (group names, IDs, or
>>> links), an array of the "groups" objects from the SCIM User schema (pages
>>> 63-64 of RFC 7643), an array of SCIM Group schema objects (pages 69-70 of
>>> RFC 7643), or something else?
>>>
>>> Will the "entitlements" claim be an array of strings (entitlement names,
>>> IDs, or links), an array of the "entitlements" objects from the SCIM User
>>> schema (pages 65-66 of RFC 7643), or something else?
>>>
>>> Sincerely,
>>>
>>> Logan Widick
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> *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.*
>
> ___

Re: [OAUTH-WG] Implementation Status of "JWT Secured Authorization Request (JAR)"

[Dominick Baier]

Also IdentityServer implements JAR

https://github.com/IdentityServer

———
Dominick Baier

On 21. September 2020 at 21:22:17, Hannes Tschofenig (
hannes.tschofe...@arm.com) wrote:

Hi all



Because some procedural issues I have to update the shepherd writeup of the
JAR document and I wanted to verify whether the implementations listed in
https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_JAR.txt
(copied below) are still inline with the latest version of
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30 (given the changes
the document has gone through*).



- List of implementations -



As part of the OpenID Foundation certification program the following



implementations of OpenID Connect Core indicate support for this



functionality:



* CZ.NIC mojeID,



* Thierry Habart's SimpleIdentitySever v.2.0.0,



* Roland Hedberg's pyoidc 0.7.7,



* Peercraft ApS's Peercarft,



* MIT's MITREidConnect,



* Gluue Server 2.3,



* Filip Skokan's node-oidc pre supports.





Authlete (https://www.authlete.com/), a commerical, closed source



server implementation, has also implemented this specification and



is offering it.





There is an open source implementation from NRI in PHP and Scala.



NRI's Open Source PHP: https://bitbucket.org/PEOFIAMP/phpoidc



-



Ciao

Hannes



PS: List of changes from the current draft to the one when I wrote my
shepherd writeup:

http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-09.txt&url2=https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-30.txt


IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
___
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] JWT Secured Authorization Request (JAR): IPR Confirmation

[John Bradley]

I know of no IPR, and make the required contributions again.

On Mon, Sep 21, 2020, 4:22 PM Hannes Tschofenig 
wrote:

> Hi Mike, Nat, John,
>
> I am updating the shepherd writeup for the "The OAuth 2.0 Authorization
> Framework: JWT Secured Authorization Request (JAR)" specification, see
> https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-30.txt, and given the
> changes I need your IPR confirmation again. (Mike joined as co-author later
> and hence I need his confirmation anyway.)
>
> One item in the template requires me to indicate whether each document
> author has confirmed that any and all appropriate IPR disclosures required
> for full conformance with the provisions of BCP 78 and BCP 79 have already
> been filed.
>
> Could you please confirm?
>
> Ciao
> Hannes
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question

[Logan Widick]

If I understand "The intent would be to present that information in the
same way you would when querying a users/, encoded in claims" correctly,
the "roles", "groups", and "entitlements" claims are the same types as the
"roles", "groups", and "entitlements" attributes of the User resource
schema (pages 24-25 of RFC 7643 for the text; pages 63-67 of RFC 7643 for
the schema)? In the schema the attributes are all "complex" (object) type
and "multivalued" (array of), although the text for some of these
attributes has some "No vocabulary or syntax..." remarks.

If that understanding is correct, it might be a good idea to replace the
references to "RFC 7643", "Section 4.1.2 of RFC 7643", and "RFC 7643,
Section 4.1.2" with something more specific like "the  attribute(s) of
the User resource schema from Section 4.1.2 of RFC 7643".

On Mon, Sep 21, 2020, 15:33 Brian Campbell 
wrote:

> At some point I'm going to be among the lucky few who will be asked to
> review the JWT claims registration request. One of the criteria to consider
> is "whether the registration description is clear" and Logan's questions
> suggest that perhaps the descriptions of these claims are not sufficiently
> clear. My assumption was that the claim value for "roles", "groups" and
> "entitlements" was going to be an array of strings. Trying to validate my
> assumption, I went looking at the text in
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-2.2.3.1
> and
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-7.2
> and followed the reference to
> https://tools.ietf.org/html/rfc7643#section-4.1.2 and, honestly, it
> wasn't particularly clear to me. Maybe it's my lack of familiarity with the
> details of SCIM and the language of RFC 7643. But I think that, for the
> sake of clarity and interoperability, some additional specificity is
> needed.
>
> Side note: the "Section 2.2.2.1 of [[this specification]]" references in
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-7.2.1
> are problmatic (there is no such section in this document) and probably
> should be to 2.2.3.1.
>
> On Fri, Sep 18, 2020 at 6:28 PM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
>
>> Hi Logan,
>>
>> Thanks for the note.
>>
>> The intent would be to present that information in the same way you would
>> when querying a users/, encoded in claims; hence groups would be a list
>> of values representing  what groups the subject belongs to, rather than a
>> list of full group definitions (with all the other members belonging to
>> them, for example) which would go beyond the intended use of the
>> information (supplying authorization information about the subject).
>>
>> I tried to keep the language high level as I didn’t want to duplicate
>> SCIM guidance, or inadvertently narrow down the options products have to
>> implement this.  If you think this is too vague, we can try to be more
>> specific.
>>
>>
>>
>> *From: *OAuth  on behalf of Logan Widick <
>> logan.wid...@gmail.com>
>> *Date: *Wednesday, September 16, 2020 at 14:21
>> *To: *"oauth@ietf.org" 
>> *Subject: *[OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question
>>
>>
>>
>> I took a look at Section 2.2.3.1: Claims for Authorization Outside of
>> Delegation Scenarios (
>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-08#section-2.2.3.1)
>> and I do not understand what exactly the formats of the "roles", "groups",
>> and "entitlements" claims will be.
>>
>> Will the "roles" claim be an array of strings (role names, IDs, or
>> links), an array of the "roles" objects from the SCIM User schema (pages
>> 66-67 of RFC 7643), or something else?
>>
>> Will the "groups" claim be an array of strings (group names, IDs, or
>> links), an array of the "groups" objects from the SCIM User schema (pages
>> 63-64 of RFC 7643), an array of SCIM Group schema objects (pages 69-70 of
>> RFC 7643), or something else?
>>
>> Will the "entitlements" claim be an array of strings (entitlement names,
>> IDs, or links), an array of the "entitlements" objects from the SCIM User
>> schema (pages 65-66 of RFC 7643), or something else?
>>
>> Sincerely,
>>
>> Logan Widick
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New podcast on identity specifications

[Vladimir Dzhuvinov]

The mTLS vs DPoP was good in articulating how the two specs are alike,
how they differ and which particular type of app they are meant to serve.

I'm saying this as a person who is generally allergic to technical
podcasts :)

Maybe every RFC that comes out of this WG should have a podcast link at
the top, where the authors discuss it in simple, honest and non-speccy
terms, because that's often how people are best able to perceive the
spirit and subtleties of some technical or spec work.

Vladimir

On 21/09/2020 09:40, Vittorio Bertocci wrote:
>
> Dear all,
>
> This is an informal mail to inform you that there’s a new podcast
> , identityunlocked.com
> , dedicated to inform and explain new
> identity specs developments for developers.
>
> You can find a more detailed explanation of the podcast’s goals in
> https://auth0.com/blog/identity-unlocked-a-podcast-for-developers/,
> but the TL;DR is that the spec themselves aren’t all that easy to read
> for the non-initiated, and a lot of useful info emerges during the
> discussions leading to the spec but rarely surface in a usable form to
> the people who don’t participate in discussions.
>
> The first episode
> ,
> featuring Brian Campbell discussing MTLS & DPoP, should give you an
> idea of what season 1 of the show will look like.
>
> The full list of the first run is available here
> .
> Of 6 episodes, 3 of them are about specifications coming out of this
> WG- and all guests are actively involved in the IETF.
>
> My main goals sharing this info here are
>
>   * *Letting you know that the podcast exists*, so that you can make
> use of it if you so choose (e.g. referring people to it if they
> need to better understand something covered in an episode)
>   * *Soliciting proposals for new episodes*: topics you believe are
> currently underserved, topics you are often asked about, topics
> you would like to be interviewed about on the show
>   * *Growing the show’s subscriber base*. I was able to get backing
> from my company to produce a podcast that has exactly ZERO product
> pitches and is purely about identity specs promotion, on the
> gamble that the topic does have an audience finding it useful. So
> far the reception has been great, and we need to keep it up if we
> want to have a season 2.  
>
>  
>
> I hope you’ll find the initiative useful!
>
> Cheers,
>
> V.
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Shepherd writeup for the JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens -- Information about Implementations

[Vladimir Dzhuvinov]

A conforming implementation and looking forward to the final spec :)

https://connect2id.com/products/server/docs/datasheet#access-token-encoding-jwt

On 17/09/2020 15:55, Hannes Tschofenig wrote:
> Hi Vittorio, Hi all,
>
> I am working on the shepherd writeup for  
> and you can find the latest version here:
> https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_JWT-Profile-for-AccessTokens.txt
>
> I am in need for information about implementations that are conformant to 
> this specification. This information would be listed in this write-up, as 
> background information to the IESG.
>
> Ciao
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth




smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [JAR] scope parameter outside request object of OIDC request

[Vladimir Dzhuvinov]

Hi Taka,

On 21/09/2020 20:12, Takahiko Kawasaki wrote:
> If we allow JAR (JWT Secured Authorization Request) to relax the
> requirement of `response_type` request parameter (outside a request
> object) from mandatory to optional, should we relax the following
> requirement of `scope` request parameter stated in OIDC Core 1.0
> Section 6.1, too?
>
> --
> Even if a scope parameter is present in the Request Object value, a
> scope parameter MUST always be passed using the OAuth 2.0 request
> syntax containing the openid scope value to indicate to the underlying
> OAuth 2.0 logic that this is an OpenID Connect request.
> --
>
> Otherwise, an authorization request like
> "client_id=...&request(_uri)=..." fails if the request object
> represents an OIDC request. An authorization request has to look like
> "client_id=...&request(_uri)=...&scope=openid" (`scope` including
> `openid` has to be given) even if the authorization server conforms to
> JAR and allows omission of `response_type` request parameter.

The bottom of section 5 has normative text which allows a JAR compliant
server to also comply with the OIDC spec with its own style of request /
request_uri parameter handling insofar as to not reject other query
params (such as scope, etc). The difference is that according to JAR
their values cannot be used or merged (as in OIDC). But what can be
reasonably done is to detect scope=openid as you say and then switch to
OIDC style request object behavior.

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30#section-5

>The client MAY send the parameters included in the request object
>duplicated in the query parameters as well for the backward
>compatibility etc.  However, the authorization server supporting this
>specification MUST only use the parameters included in the request
>object.

The confusion between the two specs clears when it's seen that the
request objects in OIDC and JAR have different objectives.

In OIDC the objective is to enable securing of selected parameters.

In JAR the objective is to secure the entire authz request.


>
> I think that implementers want to know consensus on this because it
> affects implementations. Has this been discussed yet?
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.


Vladimir



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question

[Brian Campbell]

At some point I'm going to be among the lucky few who will be asked to
review the JWT claims registration request. One of the criteria to consider
is "whether the registration description is clear" and Logan's questions
suggest that perhaps the descriptions of these claims are not sufficiently
clear. My assumption was that the claim value for "roles", "groups" and
"entitlements" was going to be an array of strings. Trying to validate my
assumption, I went looking at the text in
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-2.2.3.1
and
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-7.2
and followed the reference to
https://tools.ietf.org/html/rfc7643#section-4.1.2 and, honestly, it wasn't
particularly clear to me. Maybe it's my lack of familiarity with the
details of SCIM and the language of RFC 7643. But I think that, for the
sake of clarity and interoperability, some additional specificity is
needed.

Side note: the "Section 2.2.2.1 of [[this specification]]" references in
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-7.2.1
are problmatic (there is no such section in this document) and probably
should be to 2.2.3.1.

On Fri, Sep 18, 2020 at 6:28 PM Vittorio Bertocci  wrote:

> Hi Logan,
>
> Thanks for the note.
>
> The intent would be to present that information in the same way you would
> when querying a users/, encoded in claims; hence groups would be a list
> of values representing  what groups the subject belongs to, rather than a
> list of full group definitions (with all the other members belonging to
> them, for example) which would go beyond the intended use of the
> information (supplying authorization information about the subject).
>
> I tried to keep the language high level as I didn’t want to duplicate SCIM
> guidance, or inadvertently narrow down the options products have to
> implement this.  If you think this is too vague, we can try to be more
> specific.
>
>
>
> *From: *OAuth  on behalf of Logan Widick <
> logan.wid...@gmail.com>
> *Date: *Wednesday, September 16, 2020 at 14:21
> *To: *"oauth@ietf.org" 
> *Subject: *[OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question
>
>
>
> I took a look at Section 2.2.3.1: Claims for Authorization Outside of
> Delegation Scenarios (
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-08#section-2.2.3.1)
> and I do not understand what exactly the formats of the "roles", "groups",
> and "entitlements" claims will be.
>
> Will the "roles" claim be an array of strings (role names, IDs, or links),
> an array of the "roles" objects from the SCIM User schema (pages 66-67 of
> RFC 7643), or something else?
>
> Will the "groups" claim be an array of strings (group names, IDs, or
> links), an array of the "groups" objects from the SCIM User schema (pages
> 63-64 of RFC 7643), an array of SCIM Group schema objects (pages 69-70 of
> RFC 7643), or something else?
>
> Will the "entitlements" claim be an array of strings (entitlement names,
> IDs, or links), an array of the "entitlements" objects from the SCIM User
> schema (pages 65-66 of RFC 7643), or something else?
>
> Sincerely,
>
> Logan Widick
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

[OAUTH-WG] JWT Secured Authorization Request (JAR): IPR Confirmation

[Hannes Tschofenig]

Hi Mike, Nat, John,

I am updating the shepherd writeup for the "The OAuth 2.0 Authorization 
Framework: JWT Secured Authorization Request (JAR)" specification, see 
https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-30.txt, and given the changes 
I need your IPR confirmation again. (Mike joined as co-author later and hence I 
need his confirmation anyway.)

One item in the template requires me to indicate whether each document author 
has confirmed that any and all appropriate IPR disclosures required for full 
conformance with the provisions of BCP 78 and BCP 79 have already been filed.

Could you please confirm?

Ciao
Hannes


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

[OAUTH-WG] Implementation Status of "JWT Secured Authorization Request (JAR)"

[Hannes Tschofenig]

Hi all

Because some procedural issues I have to update the shepherd writeup of the JAR 
document and I wanted to verify whether the implementations listed in 
https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_JAR.txt
 (copied below) are still inline with the latest version of 
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30 (given the changes the 
document has gone through*).

- List of implementations -

As part of the OpenID Foundation certification program the following

implementations of OpenID Connect Core indicate support for this

functionality:

* CZ.NIC mojeID,

* Thierry Habart's SimpleIdentitySever v.2.0.0,

* Roland Hedberg's pyoidc 0.7.7,

* Peercraft ApS's Peercarft,

* MIT's MITREidConnect,

* Gluue Server 2.3,

* Filip Skokan's node-oidc pre supports.


Authlete (https://www.authlete.com/), a commerical, closed source

server implementation, has also implemented this specification and

is offering it.


There is an open source implementation from NRI in PHP and Scala.

NRI's Open Source PHP: https://bitbucket.org/PEOFIAMP/phpoidc

-

Ciao
Hannes

PS: List of changes from the current draft to the one when I wrote my shepherd 
writeup:
http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-09.txt&url2=https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-30.txt

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [JAR] scope parameter outside request object of OIDC request

[Takahiko Kawasaki]

If we allow JAR (JWT Secured Authorization Request) to relax the
requirement of `response_type` request parameter (outside a request object)
from mandatory to optional, should we relax the following requirement of
`scope` request parameter stated in OIDC Core 1.0 Section 6.1, too?

--
Even if a scope parameter is present in the Request Object value, a scope
parameter MUST always be passed using the OAuth 2.0 request syntax
containing the openid scope value to indicate to the underlying OAuth 2.0
logic that this is an OpenID Connect request.
--

Otherwise, an authorization request like "client_id=...&request(_uri)=..."
fails if the request object represents an OIDC request. An authorization
request has to look like "client_id=...&request(_uri)=...&scope=openid"
(`scope` including `openid` has to be given) even if the authorization
server conforms to JAR and allows omission of `response_type` request
parameter.

I think that implementers want to know consensus on this because it affects
implementations. Has this been discussed yet?

Best Regards,
Takahiko Kawasaki
Authlete, Inc.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Updated shepherd writeup for draft-ietf-oauth-access-token-jwt-09

[Brian Campbell]

I believe the intent of that example was to show the unencoded header and
body content of the JWT. So perhaps all that's needed is to adjust the text
that introduces the example and the figure title or caption or whatever
it's called to reflect that?

On Mon, Sep 21, 2020 at 4:58 AM Hannes Tschofenig 
wrote:

> Hi all,
>
>
>
> I updated the shepherd writeup for draft-ietf-oauth-access-token-jwt-09
> and included the links to the implementations distributed on the list. I am
> sure there are more.
>
>
>
> While updating the shepherd writeup I noticed that the draft contains a
> JWT in a style that does not match the format described in RFC 7519.
>
>
>
> I was wondering whether we should actually replicate the example in a way
> similar to Section 6.1 of RFC 7519 (which shows an unsecured JWT) or, even
> better, a digitally signed JWT.
>
>
>
> Here is the snippet from the draft:
>
>
>
>{"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"}
>
>{
>
>  "iss": "https://authorization-server.example.com/";,
>
>  "sub": " 5ba552d67",
>
>  "aud":   "https://rs.example.com/";,
>
>  "exp": 1544645174,
>
>  "client_id": "s6BhdRkqt3_",
>
>  "scope": "openid profile reademail"
>
>}
>
>
>
>
>
>Figure 2: A JWT Access Token
>
>
>
> What do you think?
>
>
>
> Ciao
>
> Hannes
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

[OAUTH-WG] Updated shepherd writeup for draft-ietf-oauth-access-token-jwt-09

[Hannes Tschofenig]

Hi all,

I updated the shepherd writeup for draft-ietf-oauth-access-token-jwt-09 and 
included the links to the implementations distributed on the list. I am sure 
there are more.

While updating the shepherd writeup I noticed that the draft contains a JWT in 
a style that does not match the format described in RFC 7519.

I was wondering whether we should actually replicate the example in a way 
similar to Section 6.1 of RFC 7519 (which shows an unsecured JWT) or, even 
better, a digitally signed JWT.

Here is the snippet from the draft:

   {"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"}
   {
 "iss": "https://authorization-server.example.com/";,
 "sub": " 5ba552d67",
 "aud":   "https://rs.example.com/";,
 "exp": 1544645174,
 "client_id": "s6BhdRkqt3_",
 "scope": "openid profile reademail"
   }


   Figure 2: A JWT Access Token

What do you think?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth