[WG-UMA] Preparing for deciding dynamic registration issues

Nat Sakimura sakimura at gmail.com
Tue Jul 27 09:24:06 EDT 2010

Several catches / opinions on the draft.

1. Client Registration Request probably needs redirect_uri as one of
the parameters
    It seems it is to this uri that the secret actually is provisioned.
2. Instead of just being "url", "client_url" or something more
descriptive would be nice.
3.Do we want "expires_in" and "issued_at" for the client_secret?
   - For example, ICAM OpenID profile requires key change every 24hours or so.
  In this respect, do we want to specify the key rotation mechanism?



On Thu, Jul 22, 2010 at 8:35 AM, Christian Scholz <cs at comlounge.net> wrote:
> Hi!
> Just FYI: I unfortunately cannot be on the call tomorrow as I am still at
> the EuroPython conference.
> Remarks below
> Am 21.07.10 23:15, schrieb Eve Maler:
> In the agenda for tomorrow I included these items:
> Dynamic registration I-D (formatted, source)
> Aim to make final decisions in this meeting
> Push vs. pull vs. both vs. merged: What UMA-specific input (e.g. around
> trusted claims) do we need to provide to help the OAuth group decide?
> Section on pushing metadata directly: moved?
> New section on extensibility: written?
> Include proposal for solution for dynamic binding of user-agent clients?
> Any other outstanding issues?
> Could those who have an opinion about the push/pull issue send a message to
> the list explaining their recommendation and rationale ahead of the call?
>  (In particular, I'm not sure I even understand how the two could be
> "merged",  as has been mentioned on the list previously...)
> So I would prefer to have only one method in there for the following
> reasons:
> - We do not have to decide when to use what and who needs to decide when to
> use what, the client or server? Probably the server need to decide that so
> there needs to be some mechanism to tell the client (probably hostmeta).
> That means that the client needs to implement both methods. So all in all
> it's more implementation work
> - Having only one method is less implementation to do on both sides. Push is
> in generall less work on both sides, too.
> - Strong auth can be done with both methods I assume.
> After the discussion last week (esp. with George) I would tend to favor push
> slightly because
> - it's easier to implement
> - it has the same security issues if you don't sign it as pull as the client
> can point the server to any URL it's supposed to read information from. OTOH
> this needs to be presented to the user so the user might be aware of this
> wrong information so I am not so sure about this anymore. You can at least
> show the user "I got information x,y,z from URL" and the user might decide
> if that is trustworthy. Maybe George can talk more on this topic though.
> As for merging: The client has to initiate the process anyway. Either it
> sends all information or it only sends a URL. So it in fact starts with a
> push. In pull you only have the information retrieval of the information
> inbetween before the server sends the response with client credentials. But
> even in push the server could choose to do that even if it's not in the
> spec. So in fact these are very similar and only differ in:
> - what the client initially sends
> - what the server does before sending a response
> But the flow is the same and only extended in the push case. It could be:
> 1. client sends client information or a URL (marked up in JSON or so)
> 2. server decides whether it has enough information and if not pulls the
> information from the client website
> 3. server sends response with client credentials (or an error message)
> Also, could anyone who feels strongly about how to accommodate
> non-web-server clients in dynamic registration propose some text ahead of
> time?
> Is there a difference in the process? The client can always initiate
> requests and in the case it's not a web server it can point to a URL on it's
> developer's website or so.
> cheers,
> Christian
> Thanks!  (I still hope to do a few typo-cleanup things to the draft sometime
> before the call...)
> Eve
> Eve Maler
> http://www.xmlgrrl.com/blog
> http://www.twitter.com/xmlgrrl
> http://www.linkedin.com/in/evemaler
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
> --
> Christian Scholz                          Homepage: http://comlounge.net
> COM.lounge GmbH                                    http://mrtopf.de/blog
> Hanbrucher Str. 33                             http://twitter.com/mrtopf
> 52064 Aachen                                             Skype: HerrTopf
> Tel: +49 241 400 730 0                                  cs at comlounge.net
> Fax: +49 241 979 00 850                                      IRC: MrTopf
> Podcasts:
> Der OpenWeb-Podcast (http://openwebpodcast.de)
> Data Without Borders (http://datawithoutborders.net)
> Politisches: http://politfunk.de/
> Technical: http://comlounge.tv/
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma

Nat Sakimura (=nat)

More information about the WG-UMA mailing list