I just noticed a minor nit.
The registration template for the meta-data attributes says:
Change controller:
For Standards Track RFCs, state IETF. For others, give the name
of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also
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
Hi all,
I am working on the shepherd writeup for the dynamic client registration
draft.
You can find the latest draft here:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_DynamicClientRegistration.txt
As you can see it is still incomplete.
I
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
Perhaps I’m just in a minority that lacks the intellectual prowess to
really understand the WS* specifications but, to me anyway, saying
that it’s clearly defined there is standing on very shaky ground.
When I read §1.3 of draft-jones-oauth-token-exchange-00[0], it sure
sounded to me like it was
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
I agree with Nat’s assessment. I’m fine updating the textual description of
the parameter, but we should not consider breaking changes to the parameter
names at this point.
Do you have specific wording in mind, Hannes?
-- Mike
From:
Was there specific language that had been discussed to be added for this? If
not, could someone please create some?
Thanks,
-- Mike
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes
I am OK with clarifying the description as privacy/data protection policy. I
don't think it needs privacy in the parameter name.
On Jul 8, 2014, at 2:59 PM, Mike Jones michael.jo...@microsoft.com wrote:
I agree with Nat’s assessment. I’m fine updating the textual description 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 ve7...@ve7jtb.com wrote:
The application_type is collected as part of
In Connect these public keys are used to:
1 verify the signature of request objects (Signed Requests), something not in
OAuth yet, and part of what the description calls higher level protocols.
2 encrypt the responses from the user_info endpoint or id_token (also not part
of OAuth directly at
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,
+1 to John's #3. The others could maybe be described in somewhat
abstract terms as examples of those higher level protocols that use
signing or encryption.
On Tue, Jul 8, 2014 at 12:33 PM, John Bradley ve7...@ve7jtb.com wrote:
In Connect these public keys are used to:
1 verify the signature of
I put it back because otherwise, we wouldn't be meeting one of the requirements
of the RFC 6749. If you look at the client registration section
http://tools.ietf.org/html/rfc6749#section-2, you'll see that registering
redirect_uri values is required, as is registering the client type. Without
Ok.
Phil
On Jul 8, 2014, at 13:38, Mike Jones michael.jo...@microsoft.com wrote:
I put it back because otherwise, we wouldn't be meeting one of the
requirements of the RFC 6749. If you look at the client registration section
http://tools.ietf.org/html/rfc6749#section-2, you’ll see that
This value was introduced in -18, and it's a direct port from OpenID Connect.
It was never in the OAuth Dynamic Registration spec, and though it has been in
the OpenID Connect Dynamic Registration spec for a very long time, I think it
was a mistake to add it in for several reasons:
First, the
If I understand correctly, this parameter is used to appropriately
constrain the schema of the Redirect URIs at the time of the registration
and is not about fulfilling the Client Type registration requirement in
section 2.1. So, making go or no-go decision based on the discussion around
section
Right, that's how it's used in Connect, which defines only redirect-based
flows. However, the OAuth version needs to be more general purpose.
It seems like this parameter really does need more discussion in the group
before it should be added to the spec, and therefore I don't think it's
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
I've updated the introspection draft based on the handful of comments that I
received from -05 to allow these discussions to be incorporated into the
discussion going forward:
http://tools.ietf.org/id/draft-richer-oauth-introspection-06.html
-- Justin
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
That's close but not quite right, since use is required by clients when using
redirect-based grant types. We could however, use this language:
The implementation and use of all client metadata fields is OPTIONAL, other
than redirect_uris
which is REQUIRED for authorization servers that
I can see where you're going with it. Requiring clients to use it implies that
servers need to enforce it. In the security considerations we currently have:
For clients that use redirect-based grant types such as
authorization_code and implicit, authorization servers MUST
require
33 matches
Mail list logo
