On 14.06.2012 06:40, John Bradley wrote:
That would probably work as well. That is why I am not particularly
concerned about excluding the :
We originally used the URI itself, mostly for convenience of
debugging, but there are other potential options.
The authorization server needs to compar
Sendt fra min Nokia-telefon
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I've incorporated a number of changes and added examples. Thanks to all for
the feedback. I can do a new draft any time if that's useful.
-bill
- Original Message -
> From: Peter Saint-Andre
> To: William Mills
> Cc: O Auth WG ; Apps Discuss
> Sent: Wednesday, June 13, 2012 8:48 A
We certainly overlap, the thing you have that is not in the link type
registrations is dynamic_client_registration_supported. We should be
consistent in naming, and ideally the OAuth related JSON elements from a JSON
format Webfinger request and your UMA stuff shoudl be identical. My concern
Probably, unless you focus the document on using these with host-meta. Also,
LRDD is itself just a link relation type so using that instead of host-meta is
probably more confusing than helpful. I would just register the link relations
to be used with future OAuth discovery via links and give hos
Also please see the UMA-flavored use cases (there are two) and the summary of
requirements provided in this input document:
http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-03
Eve
On 12 Jun 2012, at 1:39 PM, Jianhua Shao wrote:
> Hello,
>
> Dynamic client registration is very useful
Hi Bill-- In incorporating OAuth into several of the UMA flows, we found a need
for the authorization server to provide OAuth-related metadata along with
UMA-specific metadata. Originally it was strictly XRD- and hostmeta-based, but
now uses a JSON format and is more akin to OpenID Connect's met
Worthwhile to change the document title?
Examples are easy, can do.
- Original Message -
> From: Eran Hammer
> To: William Mills ; O Auth WG ; Apps
> Discuss
> Cc:
> Sent: Wednesday, June 13, 2012 9:03 AM
> Subject: RE: [OAUTH-WG] OAuth discovery registration.
>
>T hese are straigh
The registration is a simple process. You write a draft and get the designated
expert to review. They can decide to wait until the document is
published/approved or if they think it is likely to be approved, get the
registration request published earlier. They can also reject it with a reason.
On the informational status, that seemed right, but I honestly don't know what
the correct choice is here. The actual registration happens via e-mail I
believe, not via this document.
Thanks for the feedback!
-bill
- Original Message -
> From: Goix Laurent Walter
> To: Peter Saint
Thank you William for this initiative.
I had similar concerns than Peter on authn vs authz.
Under section 4.1.1 I would suggest to use "oauth2-authorize" instead of
"oauth2-authenticator", to be consistent with the "oauth2-token" pattern and
with the concepts of the oauth2 draft.
The header of
On 6/13/12 10:03 AM, Eran Hammer wrote:
> These are straight link relation registrations, not LRDD (which has no
> registration process).
Right you are!
/psa
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Hi John,
would it make sense to use a hash of the URI instead of the URI itself in your
use case?
regards,
Torsten.
John Bradley schrieb:
I think that the issues are getting confused.
There is a use case where the Authorization server may be a embedded app, at
least in one openID case.
These are straight link relation registrations, not LRDD (which has no
registration process). It is helpful to put these registrations in context and
use LRDD/host-meta as an example of their use, but the actual registration
request is simply for a link relation and nothing else.
EH
> -Ori
On 6/13/12 9:27 AM, William Mills wrote:
>
> Since for the OAUTH SASL mechanism I need discovery for clients to
> work, and I had to rip the in-band discovery out of that mechanism,
> and I need it defined somewhere, I've drafted a small doc for the
> registration of link relation types for OAuth.
Since for the OAUTH SASL mechanism I need discovery for clients to work, and I
had to rip the in-band discovery out of that mechanism, and I need it defined
somewhere, I've drafted a small doc for the registration of link relation types
for OAuth. It's too late in the process to get this into
OK cool, a use case. Does the language I suggested in another thread generally
work for you then, is something liek that needed?
>
> From: John Bradley
>To: Torsten Lodderstedt
>Cc: Julian Reschke ; Richard Mortier
>; "oauth@ietf.org"
>Sent: Wednesday, Ju
The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Framework: Bearer Token Usage'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this act
Hi all,
Just to let you know that all discusses on
draft-ietf-oauth-v2 have now cleared. So
that means that when the chairs tell me
you've finished the last few updates needed,
I can shoot this on to the RFC editor (as
long as you don't mess about adding crazy
stuff:-).
Let's get this one out th
Hi all,
Just so's you know, I've requested the additional IETF LC
on the oauth bearer draft.
This is because a reviewer after the previous IETF LC and
after the IESG telechat noticed some IPR and did the right
thing.
I think we're close enough to done that folks can make
their evaluations of wh
I think that the issues are getting confused.
There is a use case where the Authorization server may be a embedded app, at
least in one openID case.As it won't have a separate registration or token
endpoint, the client needs to make its own clientID for the request. A
reasonable thing to
agree that it'd be preferable to refer to the higher level grant
related, the spec stipulates
'The client MUST NOT make any assumptions about the timing and MUST NOT
use the token again.'
So what does the client do with it's existing access token when it
revokes the associated refresh token?
22 matches
Mail list logo
