> 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
Apologies, I misse
.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).
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
in line
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Jan 13, 2015, at 3:08 PM, Richer, Justin P. jric...@mitre.org wrote:
Hi Hannes, thanks for the review. Comments inline.
On Jan 12, 2015, at 6:11 AM, Hannes Tschofenig hannes.tschofe...@gmx.net
wrote:
Hi Justin,
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 dynamic registration
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
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
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
@ietf.orgmailto: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
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote:
+1
This gets it off the working group’s plate and lets
: [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-05 have changed
the document type
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] Dynamic Client Registration Management
@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 AM, Anthony
...@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 Management Protocol: Next
Steps?
Hi all,
in response to the discussions at the last IETF meeting the authors of the
Dynamic Client
: 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 Management Protocol: Next
Steps?
Hi all,
in response to the discussions at the last IETF meeting the authors
: Wednesday, September 10, 2014 4:50 PM
To: oauth@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
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 Management Protocol: Next
Steps?
Hi all,
in response
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 Hannes Tschofenig
Sent: Wednesday, September 10, 2014 4:50 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Dynamic
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-05
have changed
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
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 for
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
, 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 wrote:
Hi
experience.
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) Publish it as experimental
+1
div Ursprüngliche Nachricht /divdivVon: John Bradley
ve7...@ve7jtb.com /divdivDatum:11.09.2014 02:22 (GMT+01:00)
/divdivAn: Mike Jones michael.jo...@microsoft.com /divdivCc:
oauth@ietf.org /divdivBetreff: Re: [OAUTH-WG] Dynamic Client Registration
Management Protocol
-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
number of AS.
We have
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 number of AS.
We have it in Connect, the best reason
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 michael.jo...@microsoft.com wrote:
I likewise do not hold any IPR on these specs.
--
From: Phil Hunt
:* 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 Dynamic Registration specification
http://openid.net/specs
*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 Registration: IPR Confirmation
Thinking about this some more
@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 Dynamic Registration specification
http
@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 Dynamic Registration specification
http
; 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
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: IPR Confirmation
I like the idea
:* 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
, 2014 4:53 AM
To: Hannes Tschofenig; Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: IPR Confirmation
I like the idea of adding some of the text in the introduction, as I agree
the compatibility is an important (and hard-won) accomplishment. I think
taking
,
-- 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
Hi all,
in my earlier review I had
mailto: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 language, direct translation of such
can be Data Protection Policy, Personal Data Protection Policy, etc
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
-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] Dynamic Client Registration: jwks
Tschofenig
*Cc:* oauth@ietf.org mailto: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 language, direct translation of
such can be Data Protection Policy
for this? If not, could someone please create some?
Thanks, -- 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
Hi all
, 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
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
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:55 PM, Mike
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 signed request to the authorization server, as
is done in http://tools.ietf.org/html/draft
, 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:55 PM, Mike Jones wrote:
One example is when used
Hi Phil, John, Maciej, Justin, Mike,
I am working on the shepherd writeup for the dynamic client registration
document and 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
I can confirm that I have no IPR disclosures to make regarding these documents.
--Justin
/sent from my phone/
On Jul 8, 2014 7:54 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote:
Hi Phil, John, Maciej, Justin, Mike,
I am working on the shepherd writeup for the dynamic client
Hi all,
two earlier reviews I have noticed that the policy_uri meta-data
attribute is not correctly specified. I offered a suggestion and in both
cases my request was ignored.
Maybe there is a reason to reject my request but I am uncertain about
the relationship with another meta-data attribute,
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 I was told that an informal reference to a
potential use case will be added. I don't see such reference with
version -18.
Hi all,
with version -18 you guys have added a new meta-data attribute, namely
application_type.
First, this new attribute is not listed in the IANA consideration section.
Second, could you provide a bit of motivation why you need it? What
would the authorization server do with that type of
policy_uri came down from OpenID Connect Dynamic Client Registraiton 1.0
[1].
It goes:
policy_uriOPTIONAL. URL that the Relying Party Client provides to the
End-User to read about the how the profile data will be used. The value of
this field MUST point to a valid web page. The OpenID Provider
This additional information makes a lot of sense.
As you said in an earlier mail, the attempt to copy text from the OpenID
Connect spec failed a bit...
On 07/08/2014 02:49 PM, Nat Sakimura wrote:
I suppose authors has imported one of the security feature of OpenID
Connect here as well. In the
I am not against using the term Privacy Policy in the description.
Depending on the jurisdiction and language, direct translation of such
can be Data Protection Policy, Personal Data Protection Policy, etc.,
instead so just dodging it by avoiding the label would be more politically
neutral,
but it
I can confirm that I have no IPR disclosures to make on these documents.
On Jul 8, 2014, at 8:01 AM, Justin Richer jric...@mit.edu wrote:
I can confirm that I have no IPR disclosures to make regarding these
documents.
--Justin
/sent from my phone/
On Jul 8, 2014 7:54 AM, Hannes
I confirm I have no IPR disclosures on this document.
Phil
On Jul 8, 2014, at 4:54, Hannes Tschofenig hannes.tschofe...@gmx.net wrote:
Hi Phil, John, Maciej, Justin, Mike,
I am working on the shepherd writeup for the dynamic client registration
document and one item in the template
I likewise do not hold any IPR on these specs.
From: Phil Huntmailto:phil.h...@oracle.com
Sent: 7/8/2014 9:11 AM
To: Hannes Tschofenigmailto:hannes.tschofe...@gmx.net
Cc: Mike Jonesmailto:michael.jo...@microsoft.com; John
Bradleymailto:ve7...@ve7jtb.com; Justin
: 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
Subject: Re: [OAUTH-WG] Dynamic Client Registration: policy_uri
I am not against using the term Privacy Policy in the description.
Depending
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
, 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 language, direct translation of such
can be Data Protection
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 ve7...@ve7jtb.com wrote:
The application_type is collected as part of
-
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 fields is
underspecified, i.e
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,
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 fields is
underspecified, i.e., it is not clear what these fields are used
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 same thing because
] 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
number of AS.
We have it in Connect, the best
.
-- 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@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type
It was taken
-boun...@ietf.org 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 number
: oauth@ietf.orgmailto: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
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
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
Yes that is reasonable.
Sent from my iPhone
On Jul 8, 2014, at 9:44 PM, Richer, Justin P. jric...@mitre.org 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
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 michael.jo...@microsoft.com wrote:
Thinking about this some more, there is one IPR issue
.
-- 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
requirements
In draft
: Tuesday, July 08, 2014 6:44 PM
To: oauth@ietf.orgmailto: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 text, including the sentences
Hi Brian, Hi Justin,
thanks for the quick feedback.
Here is the status from the last meeting:
http://www.ietf.org/mail-archive/web/oauth/current/msg12514.html
I tried to put a date to the milestone on the charter page.
When would this work be finished?
Ciao
Hannes
On 07/03/2014 04:58 AM,
Part if the lack of consensus is lack of agreement on what mgmt is for. Until
that is resolved its hard to see what the timeline would be. Mgmt might be the
right call. Who knows.
For example i see credential rotation and client software update, and
deprovisioning as being events. I am not
Having difficulty finding consensus around a solution isn’t the same
thing as lack of interest in a solution. I think it would be very
premature to remove the Dynamic Client Registration Management
Protocol from the list of WG items.
On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig
Hi Phil,
you are right that I should have used different terminology, such as the
classification that Justin uses in his document (such as 'open
registration', 'protected registration') since the term 'enterprise' and
'web' carries a lot of other emotions and baggage that is not relevant
to
Thanks for sharing your perspective, Justin.
This is a good summary of the use cases in the appendix of
draft-richer-oauth-dyn-reg-core-00 and draft-ietf-oauth-dyn-reg-14. The
text in the appendix is more focuses on the technical aspects but I
believe the main difference really is in the
1 - 100 of 185 matches
Mail list logo
