It is not worth defining it now. It actually is harmful.
I can see developers start trusting the identifier and causing problems
later.
We should do it together with more thought out security measures.
2013/5/23 Justin Richer
> I agree with Prateek that redirect_uri isn't sufficient or well-su
I agree that any new field or fields should be defined once the requirements
and flows are well-specified and well-understood as part of a complete
specification for those flows and use cases.
-- Mike
From: oauth-boun...@ietf.org [
In fact, one of the driving factors in this draft was so that OIDC and
UMA wouldn't have to invent their own protocols and that we could
abstract the knowledge in both of these for a well-considered basic use
case. We as a working group long ago agreed that we needed to do dynamic
registration
My mistake, was to say, We already have OpenID Connect doing dynamic
registration, I don’t think there is a need to force it into OAuth.
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Wednesday, May 22, 2013 3:16 PM
To: Anthony Nadalin
Cc: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG
I agree with Prateek that redirect_uri isn't sufficient or well-suited
for this, but I also agree with John that software_id on its own doesn't
buy you a whole lot as a standalone field. It could be a reasonable
stepping stone to future, more high-assurance work, but my question is
then: is it
There are two main things that I dislike about this proposal, but
neither are insurmountable in my view.
1) Version. I think that the entire notion of "version" is as slippery a
slope as "software identifier" is in the first place. And as soon as you
start talking about "version" people are go
I dont see a big issue with a faked software_id. As i said it was a minimal
proposal with the door open to stronger assertions.
Rogue clients pretending to be something they are not is actually more evidence
of a problem. In draft 10 you cant even do that.
Phil
On 2013-05-22, at 15:15, John
I'm having trouble understanding
> We already have OAuth doing dynamic registration, I don’t think there is a
> need to force it into OAuth.
>
I would be open to a scim dyn reg version. Particularly to discuss instance
metadata mgt which scim is good at and the credential managemenr/bootstrap
At the moment for Mobile devices and other native apps all we have to reliably
identify the app is the redirect_uri.
The client_id is trivially faked in native apps.
Yes in a well groomed enterprise trusting a self asserted software identifier
is nice but probably doesn't scale to the real w
Well, I have to say that if anything seems poorly thought out, it would
be a design with the following characteristics.
[quote]
We already have a "software_id" field and it's named "redirect_uris"
[\quote]
This seems to violate the most basic principles of software design -
overloading a field
+1
We already have a "software_id" field and it's named "redirect_uris".
This doesn't seem well thought-out. We shouldn't try to jam it into the spec
at the last minute.
The good news is that since the registration spec allows for extensions, and
the proposed fields are optional, these could
I totally disagree with your characterization of SCIM, while it can be used
from server to server (provision one system to another) it can also be client
to endpoint (initial provisioning and JIT provisioning). SCIM is fairly simple
(but can be complex), I also have concerns about SCIM not being
Phil,
As I pointed out in the other thread, redirect_uri is the thing that ties
together the clients as that is the place the responses need to go to so is
hard to fake.
All instances of a particular client application will share the same
redirect_uri across all instances.
Adding a bunch
I answered some of this in my reply to Tony already, but from my
perspective it boils down to SCIM not really being that great of a fit
for this kind of use. It makes very different assumptions about who's
undertaking all of the actions, and those assumptions (which are
completely valid assumpt
I'm not sure why you don't think it's in scope, it's in the working
group's charter:
http://www.ietf.org/dyn/wg/charter/oauth-charter.html
So ... it's definitely in scope, and has been for over a year and a
half. This is the tenth version of this document-- an IETF Working Group
document at
I had a conversation with Justin yesterday to try to come to a resolution
regarding my concerns about client instances and being able to associate client
instances that are issued for the same client software. I think we made some
progress.
Background:
In RFC6749, public clients, had a common
Let's make a new thread for this. It is worth some discussion.
We have some strong cases for this, and I do think dyn reg involves some
credential management issues that SCIM doesn't yet handle.
I think Justin is planning to make these aspects more clear in the draft.
Phil
@independentid
www.
So, I really don’t understand why dynamic registration is in scope, I
understand this relative to OpenID Connect but not OAuth, if this is indeed in
scope then I would have expected that the endpoint be based upon SCIM and not
something else like what has been done here.
From: Justin Richer [ma
+1
I also agree with Justin's comment on token_endpoint_auth_method.
Never-the-less, I did want to pass along the feedback that some were confused.
The expires_at, issued_at thing though is particularly confusing (though the
text may be clear) and is a higher priority issue in my opinion.
Phil
I'm neutral with changing (1) and (2) because they're not highly breaking
changes. These are optional parameters and code already has to be prepared to
not receive them and to ignore not understood parameters. If the change is
made, the result would be that existing implementations wouldn't re
Speaking as an implementor, I'm actually in favor of changing
"expires_at" and "issued_at" to the values proposed below. It would
require some minor code changes on my end, but the impact would be
minimal, and I think that the new names are *much* more clear to new
developers. I think it will s
Coming in late to this thread: I agree broadly with Justin, Mike, and John.
Having an in-band just-in-time registration capability is valuable. By analogy
with user identifiers, it's useful for client identifiers to be issued for the
asking as the first rung of an assurance (real-world identific
Nit: section 2.1, under "token type hint", the word "parameter" is
repeated.
Otherwise a quick read through looks good to me.
-- Justin
On 05/19/2013 01:07 PM, Torsten Lodderstedt wrote:
Hi all,
this revision covers all minor issues from IETF LC.
regards,
Torsten.
Am 19.05.2013 19:04, sc
23 matches
Mail list logo
