> In fact, I've already got a vendor-specific grant type that uses an
> unregistered parameter on the token endpoint - it's a simple grant
> type for access token introspection [2].
>
> [2]
> http://documentation.pingidentity.com/display/PF66/Grant+Type+Parameter
> s#GrantTypeParameters-1079271
W
Thanks for clarifying Barry. And my apologies if I interpreted more
"push" in your comments than there really was.
I honestly can't envision the need for sub-registries so believe that
a single one is more than sufficient.
On Thu, Jun 21, 2012 at 3:10 PM, Barry Leiba wrote:
> No, there was no "
>>> Have Section 3 note that certain classes might create new
>>> sub-registries for what goes under them, if necessary.
>>
>> I honestly don't understand the push to have additional registries under
>> urn:ietf:params:oauth?
>
> I agree that one registry is sufficient. The number of registrations
As far as the rest of the policy discussion, I have no interest or
intent to define policy for this stuff. A year+ ago I needed a URI for
the SAML grant type. It could be anything but it should be something
stable. And it'd be nice if it was semi-meaningful. I was using
http://openid.net or someth
On Thu, Jun 21, 2012 at 1:48 PM, Hannes Tschofenig
wrote:
> Btw, in a discussion with Brian we check the policies for the three
> extensions in the OAuth core specification
>
> 1) Section 8.3. Defining New Authorization Grant Types
>
> If you don't define additional token endpoint parameters the
I agree that one registry is sufficient. The number of registrations won't be
huge and so having sub-registries seems like overkill.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Campbell
Sent:
I agree there but does that have anything to do with the track of this
doc (standards vs info)? Isn't that defined in the doc itself? i.e.
"The registration procedure for new entries requires a request in the
form of the following template and is subject to Expert Review per
RFC 5226 [RFC522
I honestly don't understand the push to have additional registries
under urn:ietf:params:oauth?
On Thu, Jun 21, 2012 at 1:28 PM, Barry Leiba wrote:
> This one's mostly there. As Mike and Hannes are discussing, the WG
> needs to sort out exactly what goes under "oauth" here.
>
> Here's a suggesti
I'd argue that the registration regime chosen should be flexible enough to
permit OASIS or OpenID specs to use it. Otherwise, as someone else pointed,
people will work around the limitation by using unregistered values - which
helps no one.
-- Mike
From: Barry
Btw, in a discussion with Brian we check the policies for the three extensions
in the OAuth core specification
1) Section 8.3. Defining New Authorization Grant Types
If you don't define additional token endpoint parameters then there is actually
no requirement for expert review or a specificat
Hi,
I'm trying to implement OAuth 2.0 provider support and, in particular,
right handling of errors.
Following OAuth 2.0 spec : http://tools.ietf.org/html/draft-ietf-oauth-v2-28,
I don't understand the authorization request errors : part 4.1.2.1.
If I have a valid redirection url, I understand th
>> Stephen:
>> Yeah, I'm not sure Standards Track is needed.
>
> On this bit: I personally don't care, except that we don't have to do it twice
> because someone later on thinks the opposite and wins that argument, which
> I'd rather not have at all (My one-track mind:-) Doing the 4 week last call
This one's mostly there. As Mike and Hannes are discussing, the WG
needs to sort out exactly what goes under "oauth" here.
Here's a suggestion:
Have Section 3 specify that what comes after "oauth" are one or more
tokens, delimited by ":".
Have Section 3 create the registry for the first-level tok
On 21 Jun 2012, at 19:29, Barry Leiba wrote:
>>> (1) Why Informational? Everything else at that level seems to
>>> be specified in a standards track or BCP level RFC, and IETF
>>> Consensus is required. [1] I think you have to do this as
>>> standards track. Did I miss something?
>>>
>> Standa
Hi Mike,
Thanks for your mail.
First, I would like to argue for a registry that has more than one level. We
need a two level registry because the different extensions have (and will also
in the future) have different extension policies.
The structure of the registry is: urn:ietf:params:oaut
Hi Nat ...
It could also be that RS is the PDP+PEP. Your model seem to fit this one.
Yes, exactly!
Then, you just take id_token there and PDP portion of the RS gives you the
access token, which you present it to the PEP portion of the RS.
if by "you" you're referring to the native client, th
Assuming that change is made (and I think it should be), the text in
the first paragraph of §3 should be similarly reworked.
http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03#section-3
On Thu, Jun 21, 2012 at 12:49 PM, Brian Campbell
wrote:
> I was trying to write something useful for th
I was trying to write something useful for the "Index value" while
still staying in-line with the previous revisions of doc as well as the
URNs that we've used in the SAML and JWT profiles. But I agree that
there's no need to unnecessarily restrict it to a two level structure.
On Thu, Jun 21, 201
Hi Barry,
On Jun 21, 2012, at 9:29 PM, Barry Leiba wrote:
>>> (1) Why Informational? Everything else at that level seems to
>>> be specified in a standards track or BCP level RFC, and IETF
>>> Consensus is required. [1] I think you have to do this as
>>> standards track. Did I miss something?
>>
Hi Barry,
let me describe what we are trying to do here:
1.) This document creates a new URN with urn:ietf:params:oauth.
There are procedures for creating new entries under urn:ietf:params, as
described in RFC 3553, and we have them in the document.
2.) We provide guidance on how others then
"An IETF URN Sub-Namespace for OAuth" draft -03 has been published and
is available at
http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03
Changes (listed below as well as in the document history) from the
previous version were made in response to AD review and the subsequent
discussion prom
>> (1) Why Informational? Everything else at that level seems to
>> be specified in a standards track or BCP level RFC, and IETF
>> Consensus is required. [1] I think you have to do this as
>> standards track. Did I miss something?
>>
> Standards Track is OK.
Stephen:
Yeah, I'm not sure Standards
This draft is much clearer. Thanks for the quick turn-around.
One question: You added:
*Index value: values subordinate to urn:ietf:params:oauth are of the from
urn:ietf:params:oauth:: with : as the index value
Why bake the assumption of a two-level structure into the registry?
For instance,
Hi Stephen,
thanks for the review comments. ;
On Jun 20, 2012, at 3:26 PM, Stephen Farrell wrote:
>
> Hi,
>
> Many thanks for a nice short document!
>
> I've a few questions though and suspect that a quick re-spin
> might be needed, but let's see what the wg think about 'em
> first.
>
> (1)
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : An IETF URN Sub-Namespace for OAuth
Author(s) : Brian Campbell
Hi John,
I read through your blog post. I am not sure whether I can entirely agree with
your separation between authentication and authorization. I believe the core
issue here is that
* anyone who has the token will get access to whatever the token entitles him
or her to do (unless there are
26 matches
Mail list logo
