gmane.ietf.oauth

Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata

Phil Hunt — 2013-06-19T23:36:00

Ok.  So then going down this path, is the chosen encoding method, which is LDAPish, the right way to go?  

For example, I read the spec as suggesting:

{ 
   …

       "client_name#en":"My Client",
       "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D"
  ...
}

Why not make it more JSON-esque such as:

{ 
   …

       "client_name":[
         {
          "value":"My Client",
          "lang":"en",
          "primary":"TRUE"
         }
         {
           "value":"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
           "lang":"ja-Jpan-JP"
         }
       ]
  …
}

I mention this format as it seems more JSON-like and it is more SCIM-friendly.  Also wondering if anyone knows how vCards does localization?

I agree the draft format is more compact.  But it requires more complex attribute name parsing, whereas the SCIMish expression requires more JSON parsing.

Phil

< at >independentid
www.independentid.com
phil.hunt< at >oracle.com





On 2013-06-19, at 1:55 PM, John Bradley wrote:

Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata

John Bradley — 2013-06-19T20:55:40

Yes that is an important Connect use case for Web server client registration.  Also thought of as a typical web SP.

John B.



On 2013-06-19, at 1:27 PM, Phil Hunt <phil.hunt< at >oracle.com> wrote:

Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata

Phil Hunt — 2013-06-19T17:27:05

Justin

Thanks for refreshing my mind. I forgot the web client case is acting on behalf of many users. 

Phil

On 2013-06-19, at 10:18, "Richer, Justin P." <jricher< at >mitre.org> wrote:

Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata

Richer, Justin P. — 2013-06-19T17:18:57

Your question seems to assume a one-to-one mapping between client and user, and that's not guaranteed to be the case. Think of an installed web application that's talking to an auth server, and that web application is going to talk to a number of different users. Those users can have multiple different language preferences. The human-readable fields are sent to the auth server so that the auth server can display them to the end user during the authorization screen and the application management screens. As such, it makes sense (and was requested by the working group at the last IETF) that a client can register its whole set of languages and the auth server picks the appropriate one to display to the user. 

It used to be the case that there was only a single value (unadorned with language tags) for things like client_name, and a client would've had to register itself multiple times to get at different languages. The Working Group decided that this was both too complicated and too error prone, so we adopted (

[OAUTH-WG] dyn reg - Human Readable Client Metadata

Phil Hunt — 2013-06-19T17:05:20

I am looking over the section on Human Readable Client Metadata and am a bit confused as it pertains to the rest of the specification and the implications for service providers.

Is it the intention that even single-valued client metadata may have multiple localized values?  Or, is the assumption that  a client would signal its preferred language and that ALL metadata values have only ONE localization at a time?

I started considering this when I got to the section discussing things like having client_name#ja-Jpan-JP and client_name#en.  

Would be a lot simpler to have preferredLanguage be part of the client schema and assume that all human readable fields have been localized by the client.  It seems to me to be more complex if every client registers its entire set of language translations for each piece of metadata if the user will only ever use one at a time.  Why track all variants?

My thought is that in the case of OAuth client interactions, all language localization is to drive the interface for the p

Re: [OAUTH-WG] Reusing access tokens with scopes that allow updates

Sergey Beryozkin — 2013-06-17T10:12:07

I've thought a bit more about it and I guess it is not exactly the 
OAuth2 issue, but rather an application design issue. Specifically, it 
is up to a client to decide if it wants a token be reused (for calendar 
updates while the token is valid) or not and if it wants then it should 
request a wide-enough scope at the start of the flow, example, request 
"readCalendar updateCalendar-24" and let the user to either authorize 
the calendar updates at any time of the day or downscope the requested 
scopes to allow the client to read a calendar only and then for a client 
to report the end user it can not update the calendar.

I think I'm more or less clear on this but any comments will be of 
course welcome; again - sorry if it is off-topic

Sergey

[OAUTH-WG] Reusing access tokens with scopes that allow updates

Sergey Beryozkin — 2013-06-17T09:18:02

Hi, apologies if it is off-topic, though I'm hoping it won't be completely,

I'm working on a demo where an access token allows a client to update 
the end user's resource, example, a calendar. For example, the end user 
requests a reservation service to book some event and the user may allow 
the client to update a calendar at a specific hour only.

So in the authorization code flow, it may look like this:

- client requests a code with scopes like "readCalendar 
updateCalendar-7" where "updateCalendar-7" means a request to update the 
user's calendar at 7 o'clock.
- the user approves it and subsequently the client can update a calendar 
at the request hour only.

This has worked well in the earlier version of the demo, but now that 
I've started looking into extending the demo such that the end user is 
not requested an authorization every time this user asks the reservation 
service to book something by attempting to reuse the existing access 
token I'm seeing the problems.

The client (reservation servic

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-10.txt

Torsten Lodderstedt — 2013-06-16T09:28:22

Hi,

the new revision addresses DISCUSSES and comments raised during IESG 
evaluation:

- DISCUSS by Barry Leiba: incoporated Barry's text proposal - it 
strengthens requirements on the authorization server to immediately 
revoke tokens while acknowledging the practical constraints on change 
propagation among distributed servers
- D2 by Richard Barnes: changed text to refer to respective section of 
RFC 6749 on TLS version
- description of revocation endpoint URL now refers to respective 
section of RFC 6749 (comment by Sean Turner)
- added intro to IANA section (comment by Joel Jaeggli)
- some nits and editorial changes - should cover all comments raised 
during IESG evaluation

There are two open issues
- discussion regarding the TLS version on the list
- DISCUSS regarding the mandate to use TLS (D1/Richard Barnes)

regards,
Torsten.

Am 16.06.2013 11:13, schrieb internet-drafts< at >ietf.org:

Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-revocation-09: (with DISCUSS and COMMENT)

Torsten Lodderstedt — 2013-06-15T17:58:26

Hi Richard,

thanks for your review. Please find my comments inline.

< at >oauth WG: I would like to gather opinions regarding an issue raised by 
Richard thus I'm dispatching this to the list as well.

regards,
Torsten.

Am 29.05.2013 21:08, schrieb Richard Barnes:

I see your point. Doesn't the last bullet contradict the first bullet?

subject to ongoing discussion on the WG list.


It is at the discretion of the authorization server and the resource 
owner to invalidate any token at any time w/o notifying the client. So I 
don't see a reason to handle propagated token revocation any different 
here. I agree this causes unpredictable UX but I don't see a interop issue.



Good point. Our assumption so far is that an authz server uses excactly 
one access token implementation and either supports access token 
revocation or not. What you envisions is an authz servers, which uses 
different access token implementations for different resource servers 
(probably even use cases). Correct? In order to support this us

Re: [OAUTH-WG] Review of the assertion drafts

Brian Campbell — 2013-06-07T21:58:05

Thanks for the review Hannes. I've tried to constrain and/or clarify things
as much as I could. I am confident that those who deploy these
specifications are willing to take the steps described - there are real
deployments doing so now.

The introduction in the SAML document is intended to express the use-case
(which is basically trading a SAML assertion for an access token) but it
sounds like you were looking for something else. Do you have concrete
suggestions or text you'd like to propose towards that end?

As far as an example for a client authentication with the SAML assertion
goes, there is an example that shows the HTTP request part. But not the
detailed example like there is for an assertion grant. I did consider a
similar more detailed example for client authentication but decided at the
time that it didn't add much. I'm happy to revisit that decision though, if
folks think it would be useful?







On Wed, May 29, 2013 at 1:35 PM, Hannes Tschofenig <
hannes.tschofenig< at >gmx.net> wrote:

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt

Justin Richer — 2013-06-06T19:55:54

To make sure the discussion keeps moving forward, I've just published 
another revision that incorporates changes and clarifications brought up 
by reviews from Torsten, Amanda, Tim, Hannes, Phil, and others. All 
changes are editorial in nature (non-normative).

  -- Justin

On 06/06/2013 03:36 PM, internet-drafts< at >ietf.org wrote:

Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

Justin Richer — 2013-06-06T18:19:30

Yes, this is exactly the case.

I think that signing/asserting/verifying registration information, if 
you want to do that, is better left to extensions from the basic draft. 
We have many documented use cases for using the structure and protocol 
as-is.

In BB+ we're using the initial access token mechanism to carry the 
signed information but defining discovery, token formats, and processing 
rules (and policies!) that make this actually work. We did this because 
carrying a signed chunk of information in a JWT is an established 
practice, as is using a JWT as an OAuth token, so it made sense to us. 
Putting that information inside of a software_id field with the same 
defined semantics would also be agreeable, I think, but I think we need 
a lot more eyes and hands on it. And either way, both of these 
mechanisms can be easily be built on top of the registration draft as is 
by either defining the processing of the initial access token (which is 
what BB+ does) or by defining a new metadata parameter (whi

Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

Phil Hunt — 2013-06-06T18:05:07

I think we are getting to the source of the confusion.

To me, the client POSTING to the registration endpoint in federated scenarios is usually anonymous.  It can present signed registration claims. My preference was through a non-credential vector, like  the software_id parameter.  This is just registration information.

In your case, you are defining a local access token issued to a developer inside a single domain. This is no inter-op, so no need to specify.  I still would prefer that it be defined as local registration information, but in this case ONLY I can accept it is local authorization.

In this case, the process works the same, only now the client is no longer anonymous. It is just doing instance registration.

Phil

< at >independentid
www.independentid.com
phil.hunt< at >oracle.com





On 2013-06-06, at 10:54 AM, Justin Richer wrote:

Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

John Bradley — 2013-06-06T18:00:49

+1

On 2013-06-06, at 7:54 PM, Justin Richer <jricher< at >mitre.org> wrote:

Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

Justin Richer — 2013-06-06T17:56:13

Before they register, they're neither public nor private. After they 
register, they're either public or private depending on if they want 
to/can use a client secret or equivalent to talk to the token endpoint.

Also, having a client register and allowing it to get a token through 
the client_credentials flow (without a user in the loop) is potentially 
dangerous unless things are very carefully scope-limited anyway.

  -- Justin

On 06/06/2013 01:51 PM, Phil Hunt wrote:

Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

Justin Richer — 2013-06-06T17:54:34

... My bad, you're right. I was getting my wires crossed with all these 
emails.

In my view, the initial access token is, fundamentally, an access token 
used to constrain access to the registration endpoint (not the 
configuration endpoint, and not to get "normal" access tokens). Just 
like a normal OAuth token is an opaque token used to constrain access to 
the protected resource. If you want to define anything more for either 
of those, you're going to need more work.

I'm completely on board with making those definitions, but I think it 
goes beyond registration. And if registration is silent on all of this, 
and just says "the registration endpoint may be an OAuth 2.0 protected 
resource", then whatever interoperable solutions we can come up with for 
validating a cross-domain token can be applied here. I don't think it 
makes sense to constrain registration before the rest of this work is 
baked.

  -- Justin


On 06/06/2013 01:50 PM, Phil Hunt wrote:

Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

Phil Hunt — 2013-06-06T17:51:56

When they are issued their client credential after successfully registering….isn't that the whole point of the process?

Once they register, they are no longer public.  After that, they just get a token like everyone else.

Phil

< at >independentid
www.independentid.com
phil.hunt< at >oracle.com





On 2013-06-06, at 10:49 AM, Justin Richer wrote:

Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

Phil Hunt — 2013-06-06T17:50:48

We have two separate discussions going on.  8-)

Phil

< at >independentid
www.independentid.com
phil.hunt< at >oracle.com





On 2013-06-06, at 10:48 AM, Justin Richer wrote:

Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

Justin Richer — 2013-06-06T17:49:57

Then how do they get their equivalent of a registration access token to 
manage their configurations?

The draft proposes that they get this token right from the registration 
endpoint. You're proposing that they get this from the token endpoint.

The initial access token isn't even in play here.

  -- Justin

On 06/06/2013 01:49 PM, Phil Hunt wrote:

Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

Phil Hunt — 2013-06-06T17:49:33

Huh?

There's no need for public clients to access the token endpoint as they can register anonymously.

Phil

< at >independentid
www.independentid.com
phil.hunt< at >oracle.com





On 2013-06-06, at 10:47 AM, Justin Richer wrote:

Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

Justin Richer — 2013-06-06T17:48:29

I thought we were talking about the registration access token, not the 
initial access token?

  -- Justin

On 06/06/2013 01:48 PM, Phil Hunt wrote: