Client doesn't need to *be* a web server, just *have* a web server available.
EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of George Fletcher > Sent: Friday, June 11, 2010 9:25 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri > > On 6/11/10 12:07 PM, Marius Scurtescu wrote: > > On Fri, Jun 11, 2010 at 8:59 AM, David Recordon<record...@gmail.com> > wrote: > > > >> That sounds like a security consideration to me! :) > >> > >> I imagine that authorization servers will verify ownership in > >> different manners depending on their tolerance of risk. > >> > > Instead of POSTing a JSON with all the details, dynamic binding could > > send only a host name. The authz server would then do discovery on > > this host and get a pointer to this JSON from host-meta. > > > > Marius > > > > > I think most all of this could be described in the host-meta XRD directly to > save yet another round trip. And I believe there are some security > advantages to using this approach, but it does require the "client" to be a > web-server. This might not always be the case (rich desktop app). For > native/desktop apps, it seems that posting some set of parameters > (equivalent security-wise to a browser user-agent) makes sense and keeps > the protocol simple. > > Thanks, > George > >> > >> On Fri, Jun 11, 2010 at 8:54 AM, Marius > Scurtescu<mscurte...@google.com> wrote: > >> > >>> On Fri, Jun 11, 2010 at 8:35 AM, Christian Scholz<c...@comlounge.net> > wrote: > >>> > >>>> Hi! > >>>> > >>>> Am 11.06.10 17:05, schrieb Justin Richer: > >>>> > >>>>> Along these lines, I'd like to propose an extension for per-client > >>>>> instance information to be passed from a client to the server. > >>>>> Things like a human-readable client name/description, instance > >>>>> name/description (could be tied to host name, ip, label like > >>>>> "home" or "Work"), and even something like a display icon. This is > >>>>> especially useful for things like device clients (where I might > >>>>> have a bunch of devices with the same client ID) or unregistered > >>>>> clients, where the client id string ends up being closer to a > >>>>> user-agent string from a browser than a trusted identifier, especially > since it can't have a reliable secret. > >>>>> > >>>> We have the need for dynamic binding of clients in the User Managed > >>>> Access group (UMA) as well. I did look into OpenID Connect but felt > >>>> that reusing an OAuth flow based on a different type is maybe > >>>> mixing things a bit too much. To me using a flow means that in the > >>>> end usually you end up with an access token which here is not the > >>>> case. Especially I don't like the reuse of the token URI as IMHO > >>>> it's better to use separate endpoints for different APIs. > >>>> > >>>> I thus went along and crafted some simple handshake in the UMA > >>>> specification which I also wanted to move out into a single > >>>> specification over the next days. > >>>> > >>>> You can find it here: > >>>> > >>>> http://kantarainitiative.org/confluence/display/~christianscholz/St > >>>> ep+1+experimental+version+v1 > >>>> > >>>> under "Dynamic binding of OAuth clients". > >>>> > >>>> It is a simple handshake where you provide a JSON formatted client > >>>> descriptor containing the information you describe above and the > >>>> results is a set of client credentials plus optionally additional > >>>> information (in UMA we eventually need to pass back more > >>>> information like additional endpoints). > >>>> > >>> In general during registration an authz server will verify that the > >>> client really owns the domain it claims it does. Does any validation > >>> like that happen in the suggested "Dynamic binding of OAuth clients"? > >>> > >>> Marius > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
