[WG-UMA] New version of draft

Christian Scholz cs at comlounge.net
Tue Jul 20 11:11:02 EDT 2010


 Hi!

Am 20.07.10 14:56, schrieb Eve Maler:
> Catching up slowly from last week's absence...  I see that these
> matters were discussed in the telecon last week. Here is an attempted
> summary of the state of play; let me know if I've got it wrong.
>
> Trust framework certification is a real-life example of why it's
> useful to strongly authenticate the client. The client ("RP") metadata
> as a whole could be signed by the client itself and the signature
> could be verified by the authz server (credential issuer), and/or
> individual pieces of metadata could be signed e.g. by the trust
> framework provider.
>
> So a question for us would be: Does requirement 2.3, "The
> authorization server must have the option of strongly authenticating
> the client and its metadata", suggest that we should specify exactly
> /how/ to achieve this in our I-D proposal? It seemed like people were
> interested in documenting how to sign "pushed" metadata as well as how
> to handle signed metadata that is "pulled". I'm thinking it would be
> simpler to assume that the push case is low-authentication/assurance,
> and leave signing out of the picture, concentrating on the
> higher-authentication case only for pull.

Well, the question was more if we need both push and pull ;-) The
problem with pull is (as George pointed out) that the client can give
any URL endpoint the server will then pull information from. So this is
not any more secure than pushing the data in the first place. Which
means that you need signing anyway if you assume that users will not
really check URLs.  And if pull does not provide any more security then
we might go with push directly.

As for including a signing process I would suggest to not include it as
we need to decide on one then ;-) I would include some example section
at least for discussion which can be left out in the final spec.
Somebody suggested to do it that way because otherwise people might take
this as how to do it. (IIRC).

> So, does the dynamic registration I-D need to be revised according to
> last week's discussion?  What needs to happen to get it into final
> shape for contribution?
Unfortunately I am this week out and don't have much time for this but I
made notes I wanted to include there. We still need to decide on which
methods we want to include. As said before, the lower the number the
better for getting it implemented. And push is also easier on both sides
than pull.

But feedback on this point is still welcome! Maybe we can find some
consensus. We can also decide to let the OAuth group decide.

Besides that I think it's mostly small stuff which shouldn't prevent a
submission as it will get worked on anyway. But some proofreading might
be good.

cheers,

Christian


-- 
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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20100720/3ec78aaa/attachment-0001.html 


More information about the WG-UMA mailing list