Hi Christian,
thanks for clarification.
Regards, Stefanie
Am 11.08.2010 18:22, schrieb Christian Scholz:
Hi!
Am 11.08.10 16:36, schrieb Stefanie Dronia:
Hallo Eve,
I read your proposal, too. Thanks for providing it.
Some questions:
# first part of chapter 2
# enchanced OAuth RS, AS and client are mentioned. Does the
enhancement just denote, that they support dynamic client registration
or have any further requirements to be fulfilled by them?
These are mostly examples from the User Managed Access (UMA) Working
Group where we use components which have to do a bit more than simple
OAuth. Out of this came the need for dynamic client registration which
we thought might be useful in other OAuth contexts as well.
So regarding the actual client registration they do not need to have
further requirements other than the client registration capabilities
described. In the final version we might want to get rid of the UMA
specific text in order to prevent confusion.
# The text is "... use an access token in approximately the normal
OAuth fashion,...": What do you mean by "approximately" in this context?
As far as I understood, after client registration, OAuth flows are
performed as defined.
Yes, again this relates to our UMA use cases where later on (after
client registration) those components need to do a bit more. For this
spec though this is irrelevant.
# For registration, the client has to give its URL (parameter client_url
in registration request). May it be used later for OAuth callback url,
e.g. if client registration with pushed metadata is selected?
Those parameters basically should represent what you otherwise would
enter into a registration form like http://dev.twitter.com/apps/new
Thus there probably need to be more fields in there but website url (or
client_url) and callback_url should probably be 2 different attributes.
The question regarding the client metadata is how much information
really is needed. For manual registration the server can ask as much as
it wants. For automatic registration I would like some basic set of
attributes, some maybe being optional. The question might be which ones
to take.
And just a typo: Example chapter 7.1: "url" instead of "client_url" is
printed.
Right, thanks!
-- Christian
Regards,
Stefanie
Am 10.08.2010 21:31, schrieb Eve Maler:
Folks-- The UMA group has produced the following I-D as input to the
OAuth discovery/registration/binding discussion. We wanted to set
forth our requirements (knowing that there may be other requirements
from the wider community) and propose some solutions that meet them.
If further discussion seems to warrant an updating of this draft,
we're happy to do that. (If you have interest in getting involved in
UMA-specific work, feel free to drop me a note.)
Eve
http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt
Begin forwarded message:
From: IETF I-D Submission Tool<idsubmiss...@ietf.org>
Date: 10 August 2010 12:23:59 PM PDT
To:e...@xmlgrrl.com
Cc:c...@comlounge.net,m.p.machu...@ncl.ac.uk
Subject: New Version Notification for draft-oauth-dyn-reg-v1-00
A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been
successfully submitted by Eve Maler and posted to the IETF repository.
Filename: draft-oauth-dyn-reg-v1
Revision: 00
Title: OAuth Dynamic Client Registration Protocol
Creation_date: 2010-08-10
WG ID: Independent Submission
Number_of_pages: 20
Abstract:
This specification proposes an OAuth Dynamic Client Registration
protocol.
The IETF Secretariat.
Eve Maler
http://www.xmlgrrl.com/blog
http://www.twitter.com/xmlgrrl
http://www.linkedin.com/in/evemaler
_______________________________________________
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
