On Tue, Nov 20, 2018 at 12:45 PM Filip Skokan wrote:
> This is my best shot at an implementable policy when it comes to clients
> with expired client secrets: *"all operations requiring a secret will be
> rejected when an expired one is presented"*
>
This is a good list and hopefully something t
.@ietf.org> on behalf
of Filip Skokan <mailto:panva...@gmail.com>
Date: Wednesday, November 28, 2018 at 9:11 AM
To: George Fletcher <mailto:gffle...@aol.com>
Cc: oauth <mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
Apologie
this
e-mail.
差出人: OAuth (Joseph Heenan の代理)
送信日時: 木曜日, 11月 29, 2018 5:19 午後
宛先: oauth
件名: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
Hi all,
It’s worth adding that a per-instance dynamic registration of a native client
can still imply a higher
.org/html/rfc8252#section-8.6> still apply.
>> --
>> Annabelle Richard Backman
>> AWS Identity
>>
>>
>> From: OAuth <mailto:oauth-boun...@ietf.org> on
>> behalf of Filip Skokan <mailto:panva...@gmail.com>
>> Date: Wednesday, November 28
lf of Filip Skokan
>
> Date: Wednesday, November 28, 2018 at 9:11 AM
> To: George Fletcher
> Cc: oauth
> Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
>
> Apologies, I missed the issued in "issued a shared secret", just reading
> "sha
Apologies, I missed the *issued* in "issued a shared secret", just reading
"shared secret" alone is the exact opposite of a per-instance secret. The
rest is clear and as you say it brings the benefit of the secret never
being sent over the wire (except during the initial registration via TLS).
Bes
It's "confidential" in that the shared secret is unique to that app
instance registration (as Dennis described in his response). If an
attacker gets my phone and compromises the data stored on my device,
they only get the secret for my device. This is no different than a
server side client havi
Hi George,
#2 doesn't seem confidential, it's still a secret shared amongst
installations and anyone reverse engineering the apk, extracting the
secret, can form the client_secret_jwt client_assertion with it just fine.
Best,
Filip
On Wed, Nov 28, 2018 at 4:48 PM George Fletcher wrote:
> In ad
In addition, a few additional patterns are enabled...
1. The native app can generate a public/private key pair and then use
private_secret_jwt as the client credential validation method via the
client credentials flow (defined in OpenID Connect).
2. Maybe more simply, if the native app is iss
If the secret is dynamically provisioned then you have a confidential
client. Anyone reverse engineering their own installation of the native app
would only extract their own client's credentials, as opposed to the shared
secret of all installations. Having a confidential client means that
requests
Hi,
we just stumbled upon this [1] statement:
"Except when using a mechanism like Dynamic Client Registration
[RFC7591] to provision per-instance secrets, native apps are
classified as public clients ..."
What does this mean for us? Native App + Dynamic Client Registration =
Confidential Cl
Hi all,
a recent query about expiring client credentials (secrets) got me thinking
about client_secret_expires_at client metadata from RFC 7591 used also in
7592 as well as OpenID Connect Dynamic Client Registration 1.0
*What does expired client secret (in the sense of client_secret_expires_at
wi
Hi Matt
To add to George's point I think software statements solve your issue.
For an example of how they are being used by UK OpenBanking please look
here:
https://bitbucket.org/openid/obuk/src/4630771db004da59992fb201641f5c4ff2c881f1/uk-openbanking-registration-profile.md?at=master&fileviewer=fi
Hi Matt,
I think your use case is fully within the use cases enabled by
software-statements.
A per client software-statement allows you to tighten the security model
(if desired). For example binding the software-statement to the client
presenting it in such a way as to have a cryptographic
Hi George,
That did occur to me. It seemed like a bit of an abuse of the
software-statement system, but maybe it is partially intended for this.
It still needs us to securely distribute the software statement as well. Would
you envisage a single software-statement for all installations, with ea
Given that you have a federation, could not the federation issue the
signed software-statement to each of the relying parties (existing or
old) and the AS will trust the dynamic client registration if and only
if the signed software-statement is signed by the federation. This fits
more closely
Hi,
I am working on a use case of OAuth 2.0 in a federation and am after some
advice about bootstrapping trust.
Each site in the federation has an OAuth 2.0 authorization server and an OAuth
2.0 relying party. The relying party at each site needs to be registered with
all the authorization ser
Hi,
We'll experiment with starting supporting a "resource_uris" extension
array property - the name is based on a 'resource' indicator property
from the resource indicators draft, with a '_uris' added given that many
dynamic registration properties have similar suffixes
Cheers, Sergey
On 29/1
Hi John, All
I've been alway thinking that the reason an audience can be an array (as
indicated for ex by the JWT spec, etc) is because a client application
may need to talk to more than one RS in order to complete a single
action for the current user (ex, the client will not talk to either RS
To make something like this work with a loose coupling between the RS and AS
the format of the AT would also need to be specified.
To this point the WG has avoided standardizing AT.
Most AS probably believe they know what RS the token is going to be used at
based on scopes.
Taking those token
Hi Justin
Thanks, may be if a value for that field is not set, then, by default, a
client can use the access tokens against the arbitrary RS servers, as
far as I understand this is what happens by default right now ?
Cheers, Sergey
On 28/11/16 18:47, Justin Richer wrote:
I would consider th
I would consider that a totally reasonable extension. You will need to define
what the behavior is if the client doesn’t provide a value for that field: is
there a default? Are there no resources available to the client?
— Justin
> On Nov 28, 2016, at 12:21 PM, Sergey Beryozkin wrote:
>
> Hi
Hi All
Our AS allows for the manual client registration with the UI offering an
option to assign the audience/resource URIs to a given Client
registration with all the associated future access tokens inheriting them.
The client will not have to follow the resource indicator registration
as r
The kid in the JWT is the most appropriate thing if the iss has reregistered a
jwks_uri. If you send a jwks_uri the AS needs to have some trust model to
match the "iss" to that jwks_uri that we haven't described for Connect or Oauth
at this point.
Mostly we have been sticking to jwks that are
If you're using them for the token endpoint, you set your
token_endpoint_authorization_method to a method that supports it (which
we don't define in OAuth but other protocols and profiles do). Then
you'll usually reference them using the 'kid' field defined in JWK, or
you might just use the onl
Hi Justin, Hi all,
In context of the draft-ietf-oauth-pop-key-distribution-01 update we
just ran into a question regarding key naming.
The Dynamic Client Registration Protocol defines these two parameters
that allow a client to upload a public key to the authorization server:
jwks_uri
U
We have used the dynamic client registration API for building portals for
developers to register clients.
I am seeing that across several telco operators at the moment.
Yes everyone could have custom web pages but this is at-least a common way to
build that sort of thing.
This is not just abo
Hi Hannes, thanks for the review. Comments inline.
On Jan 12, 2015, at 10:10 AM, Hannes Tschofenig
wrote:
> Hi Justin, Hi all,
>
> I re-read the latest version of the dynamic client registration
> management document and I still have a few issues with the document.
>
> Let me start with the d
>>
>>> It also does not make sense to
>>> show the developer in the box together with the client since the
>>> developer does not execute a protocol exchange with the client
>>> registration endpoint.
>>
>> That's not true, a developer (person or organization) could very easily be
>> using the d
in line
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
> On Jan 13, 2015, at 3:08 PM, Richer, Justin P. wrote:
>
> Hi Hannes, thanks for the review. Comments inline.
>
> On Jan 12, 2015, at 6:11 AM, Hannes Tschofenig
> wrote:
>
>> Hi Justin, Hi all,
>>
>> as noted in my sta
Hi Hannes, thanks for the review. Comments inline.
On Jan 12, 2015, at 6:11 AM, Hannes Tschofenig
wrote:
> Hi Justin, Hi all,
>
> as noted in my status update I am trying to finalize the pending items.
>
> Hence, I re-read the draft-ietf-oauth-dyn-reg-21 document since my
> review of draft-ie
Hi Justin, Hi all,
I re-read the latest version of the dynamic client registration
management document and I still have a few issues with the document.
Let me start with the document structure.
When you look at the ToC you will notice that there is something wrong.
2. Client Configuration E
Hi Justin, Hi all,
as noted in my status update I am trying to finalize the pending items.
Hence, I re-read the draft-ietf-oauth-dyn-reg-21 document since my
review of draft-ietf-oauth-dyn-reg-management raised some questions
about the terminology.
If you look at the structure of the ToC then yo
.ietf.org/iesg/informational-vs-experimental.html
> >>>>
> >>>> And the discussion in Toronto, it's clearly experimental.
> >>>>
> >>>> -- Justin
> >>>>
> >>>>> On Sep 11, 2014, at 10:36 AM, Anth
experimental.
>>>>
>>>> -- Justin
>>>>
>>>>> On Sep 11, 2014, at 10:36 AM, Anthony Nadalin
>>>>> wrote:
>>>>>
>>>>> Is "experimental" the correct classification? Maybe "informational&qu
>> According to the guidelines here:
>>>>
>>>> https://www.ietf.org/iesg/informational-vs-experimental.html
>>>>
>>>> And the discussion in Toronto, it's clearly experimental.
>>>>
>>>> -- Justin
>>>>
>>
2014, at 10:36 AM, Anthony Nadalin
>>>> wrote:
>>>>
>>>> Is "experimental" the correct classification? Maybe "informational" is
>>>> more appropriate as both of these were discussed.
>>>>
>>>> -Or
;>>
>>> Is "experimental" the correct classification? Maybe "informational" is more
>>> appropriate as both of these were discussed.
>>>
>>> -Original Message-
>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hanne
f these were discussed.
>>
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Wednesday, September 10, 2014 4:50 PM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Dynamic Client Registration Manage
oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next
Steps?
According to the guidelines here:
https://www.ietf.org/iesg/informational-vs-experimental.html
And the discussion in Toronto, it's clearly experimental.
-- Justin
On Sep 11, 2014, at 10:36 A
"informational" is more
> appropriate as both of these were discussed.
>
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, September 10, 2014 4:50 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG
uth@ietf.org
Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps?
Hi all,
in response to the discussions at the last IETF meeting the authors of the
"Dynamic Client Registration Management Protocol"
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management
org<mailto:oauth@ietf.org>
Betreff: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next
Steps?
+1
Sent from my iPhone
On Sep 10, 2014, at 9:07 PM, Mike Jones
mailto:michael.jo...@microsoft.com>> wrote:
+1
This gets it off the working group’s plate and lets us gather dat
+1
Ursprüngliche Nachricht Von: John Bradley
Datum:11.09.2014 02:22 (GMT+01:00)
An: Mike Jones Cc:
oauth@ietf.org Betreff: Re: [OAUTH-WG] Dynamic Client Registration
Management Protocol: Next Steps?
+1
Sent from my iPhone
On Sep 10, 2014, at 9:07 PM, Mike Jones wrote
xperience.
>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
> Sent: Wednesday, September 10, 2014 5:05 PM
> To: Hannes Tschofenig; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next
> Steps?
>
> a) Pub
ptember 10, 2014 5:05 PM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next
Steps?
a) Publish it as experimental. There was reasonable support for this in both
Toronto and London.
-- Justin
On 9/10/2014 7:50 PM, Hannes Tschofenig
a) Publish it as experimental. There was reasonable support for this in
both Toronto and London.
-- Justin
On 9/10/2014 7:50 PM, Hannes Tschofenig wrote:
Hi all,
in response to the discussions at the last IETF meeting the authors of
the "Dynamic Client Registration Management Protocol"
http:
Hi all,
in response to the discussions at the last IETF meeting the authors of
the "Dynamic Client Registration Management Protocol"
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have
changed the document type to "Experimental".
We need to make a decision about the next steps
Hi all,
I have just sent the Dynamic Client Registration document to the IESG.
The final shepherd write-up for the document can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/shepherdwriteup/
Ciao
Hannes
signature.asc
Description: OpenPGP digital signature
;>>> -- Justin
>>>>
>>>>
>>>> On Jul 8, 2014, at 4:38 PM, Mike Jones wrote:
>>>>
>>>>> I put it back because otherwise, we wouldn't be meeting one of the
>>>>> requirements of the RFC 6749. If you look
49. If you look at the client registration section
> http://tools.ietf.org/html/rfc6749#section-2 [1], you'll see that registering
> redirect_uri values is required, as is registering the client type. Without
> this, there wasn't a way to register the client type.
>
&g
f the OpenID document. The copying all went in the other
>> direction.
>>
>> If portions of the UMA draft remained from -00 in the current drafts,
>> I'd be fine with the UMA attribution, but in practice they don't. The
>> UMA content was replaced with the OpenID Connect content. (I believ
: Mike Jones; Hannes Tschofenig; oauth@ietf.org
<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
It's quite true that the OIDC draft predates -00 of the IETF
draft, and I'm sorry if that was unclear from what I said as I was
;d be fine with the UMA attribution, but in practice they don't. The
> > UMA content was replaced with the OpenID Connect content. (I believe
> > that eventually UMA decided to drop their old draft and move to
> > registration mechanisms that were compatible with Connect as well,
ecification in the
acknowledgement?
-- Mike
-Original Message-
From: Justin Richer [mailto:jric...@mit.edu]
Sent: Wednesday, July 16, 2014 5:54 AM
To: Mike Jones; Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
gistration can be compatible with one another.
--
Mike
*From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Mike
Jones
*Sent:* Tuesday, July 08, 2014 7:15 PM
*To:* Phil Hunt; Hannes Tschofenig
*Cc:* Maciej Machulak; oa
g their previous registration
data formats.)
-- Mike
-Original Message-
From: Justin Richer [mailto:jric...@mit.edu]
Sent: Wednesday, July 16, 2014 4:53 AM
To: Hannes Tschofenig; Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: I
Of *Mike Jones
*Sent:* Tuesday, July 08, 2014 7:15 PM
*To:* Phil Hunt; Hannes Tschofenig
*Cc:* Maciej Machulak; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
Thinking about this some more, there is one IPR issue that we need to
address before publication.
gt; Portions of this specification are derived from the OpenID Connect
> >>> Dynamic Registration [OpenID.Registration] specification. This was
> done
> >>> so that implementations of this specification and OpenID Connect
> Dynamic
> >>> Registration can be
tions of this specification and OpenID Connect Dynamic
>>> Registration can be compatible with one another.
>>>
>>>
>>>
>>> -- Mike
>>>
>>>
>>>
>>> *From:*
nect Dynamic
Registration can be compatible with one another.
-- Mike
*From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Mike Jones
*Sent:* Tuesday, July 08, 2014 7:15 PM
*To:* Phil Hunt; Hannes Tschofenig
*Cc:* Maciej Machulak; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Dynamic Client Regist
il Hunt; Hannes Tschofenig
> *Cc:* Maciej Machulak; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
>
>
>
> Thinking about this some more, there is one IPR issue that we need to
> address before publication. This specification is
Hi,
My apologies for a late reply. Same here, no IPR disclosures to make
regarding these documents.
Kind regards,
Maciej
On 8 July 2014 19:06, Mike Jones wrote:
> I likewise do not hold any IPR on these specs.
> --
> From: Phil Hunt
> Sent: 7/8/2014 9:11 AM
: Phil Hunt; Hannes Tschofenig
Cc: Maciej Machulak; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
Thinking about this some more, there is one IPR issue that we need to address
before publication. This specification is a derivative work from the OpenID
Connect
4:25 AM
> To: John Bradley; Mike Jones
> Cc: Nat Sakimura; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri
>
> Here is the text from the OpenID Connect spec (as provided by Nat):
>
> > policy_uri
> > OPTIONAL. URL that the Relying Part
-Original Message-
>> From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
>> Sent: Monday, July 14, 2014 10:57 AM
>> To: Mike Jones; Brian Campbell; John Bradley
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri
>&g
; Brian Campbell; John Bradley
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri
>
> That would then be a reference to an individual draft ;-)
>
> On 07/14/2014 07:55 PM, Mike Jones wrote:
>> One example is when used as a
om: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Monday, July 14, 2014 10:57 AM
To: Mike Jones; Brian Campbell; John Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri
That would then be a reference to an individual draft ;-)
On 07/14/2014 07:5
That would then be a reference to an individual draft ;-)
On 07/14/2014 07:55 PM, Mike Jones wrote:
> One example is when used as a signed request to the authorization server, as
> is done in http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05.
signature.asc
Description: OpenPGP digital
, 2014 10:45 AM
To: Mike Jones; Brian Campbell; John Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri
Hi Mike,
sticking with working group document is fine.
However, the first example does not make sense to me.
[maybe my brain is a bit empty at the
Sent:
> Monday, July 14, 2014 2:42 AM To: Brian Campbell; John Bradley Cc:
> oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration:
> jwks / jwks_uri
>
> What about the following text:
>
> jwks_uri
>
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18&
-- Mike
>>
>> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Nat
>> Sakimura
>> *Sent:* Tuesday, July 08, 2014 6:26 AM
>> *To:* Hannes Tschofenig
>> *Cc:* oauth@ietf.org <mailto:oauth@ietf.org>
Section 4.2 of [I-D.ietf-oauth-assertions]."
-- Mike
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, July 14, 2014 2:42 AM
To: Brian Campbell; John Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG
Here is a short summary of the recent conversations regarding the
dynamic client registration draft.
In a nutshell, we will have to put the document on the agenda for the
meeting.
Items discussed on the list:
* IPR confirmation
Include a statement indicating that this specification is a derivat
t; *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Nat Sakimura
>> *Sent:* Tuesday, July 08, 2014 6:26 AM
>> *To:* Hannes Tschofenig
>> *Cc:* oauth@ietf.org <mailto:oauth@ietf.org>
>> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration: policy_uri
>
wrote:
>>
>>> Was there specific language that had been discussed to be added for this?
>>> If not, could someone please create some?
>>>
>>> Thanks,
>>> -- Mike
>>>
>>> -Original M
lients using redirect-based
>>> grant types MUST implement support for this metadata value and clients that
>>> use redirect-based grant types MUST use this parameter.
>>>
>>> -- Mike
>>>
&
Using "redirection URIs" is fine with me.
From: Richer, Justin P. [mailto:jric...@mitre.org]
Sent: Tuesday, July 08, 2014 8:57 PM
To: Mike Jones
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata
requirements
Well, I think it's conf
using the “redirect_uris” parameter.
-- Mike
From: Richer, Justin P. [mailto:jric...@mitre.org]
Sent: Tuesday, July 08, 2014 8:41 PM
To: Mike Jones
Cc: oauth@ietf.org<mailto:oauth@ietf.org> list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comme
8:41 PM
To: Mike Jones
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata
requirements
Also, I just noticed that paragraph has a typo: "redirect_uri" should be
"redirect_uris".
-- Justin
On Jul 8, 2014, at 11:39 PM, Justin Richer
y, July 08, 2014 8:39 PM
To: Mike Jones
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata
requirements
I can see where you're going with it. Requiring clients to use it implies that
servers need to enforce it. In the security considerati
ant types MUST use this parameter.
>>
>> -- Mike
>>
>>
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richer, Justin P.
>> Sent: Tuesday, July 08, 2014 6:44 PM
>> To: oauth@ietf.
this metadata value and clients that use
redirect-based grant types MUST use this parameter.
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richer, Justin P.
Sent: Tuesday, July 08, 2014 6:44 PM
To: oauth@ietf.or
On Behalf Of Richer, Justin P.
Sent: Tuesday, July 08, 2014 6:44 PM
To: oauth@ietf.org<mailto:oauth@ietf.org> list
Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata
requirements
In draft -18, we clarified the optionality of the client metadata parameters in
§ 2 with new te
this parameter.
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richer, Justin P.
Sent: Tuesday, July 08, 2014 6:44 PM
To: oauth@ietf.org list
Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata
require
Yes Nat and I mentioned the need for attribution to Hannes.
Having that also helps clarify the relationship between the specs for readers.
Sent from my iPhone
> On Jul 8, 2014, at 10:14 PM, Mike Jones wrote:
>
> Thinking about this some more, there is one IPR issue that we need to address
>
Yes that is reasonable.
Sent from my iPhone
> On Jul 8, 2014, at 9:44 PM, "Richer, Justin P." wrote:
>
> In draft -18, we clarified the optionality of the client metadata parameters
> in § 2 with new text, including the sentences:
>
> The implementation and use of all client metadata fields
Thinking about this some more, there is one IPR issue that we need to address
before publication. This specification is a derivative work from the OpenID
Connect Dynamic Registration specification
http://openid.net/specs/openid-connect-registration-1_0.html. Large portions
of the text were co
In draft -18, we clarified the optionality of the client metadata parameters in
§ 2 with new text, including the sentences:
The implementation and use of all client metadata fields is OPTIONAL, other
than "redirect_uris".
redirect_uris (...) Authorization servers MUST implement support for th
th [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, July 08, 2014 12:37 PM
To: Phil Hunt
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type
It was taken out and then put back in as it is a common parameter used
stering the client
> type. Without this, there wasn’t a way to register the client type.
>
>
>
> -- Mike
>
>
>
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org ] On
> Behalf Of
uri values is required, as is registering the client type. Without
this, there wasn’t a way to register the client type.
-- Mike
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, July 08, 2014 12:37 PM
To: Phil Hunt
Cc: oauth@
oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Tuesday, July 08, 2014 12:37 PM
> To: Phil Hunt
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type
>
> It was taken out and then put back in as it is a common parameter used by a
&
oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type
It was taken out and then put back in as it is a common parameter used by a
number of AS.
We have it in Connect, the best reason for keeping it is to stop people from
coming up with a new parameter for the sam
-- Mike
>>
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Tuesday, July 08, 2014 5:09 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri
>
It was taken out and then put back in as it is a common parameter used by a
number of AS.
We have it in Connect, the best reason for keeping it is to stop people from
coming up with a new parameter for the same thing because they haven't looked
at the Connect version.
John B.
On Jul 8, 2014, a
ge-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, July 08, 2014 5:09 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri
>
> Hi all,
>
> in my earlier review I had noted that the semantic of the
Does this need to be in the spec? I believe we’ve already said that others can
add attributes as they need.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Jul 8, 2014, at 11:56 AM, John Bradley wrote:
> The application_type is collected as part of current registration by
> Sent: Tuesday, July 08, 2014 6:26 AM
> To: Hannes Tschofenig
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri
>
> I am not against using the term "Privacy Policy" in the description.
> Depending on the jurisdiction and languag
Tschofenig
Sent: Tuesday, July 08, 2014 5:09 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri
Hi all,
in my earlier review I had noted that the semantic of the fields is
underspecified, i.e., it is not clear what these fields are used for.
In private conversations
1 - 100 of 210 matches
Mail list logo
