Subject: [OAUTH-WG] Extensibility for OAuth?

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 23 Jun 2010 09:07:41 +0300

Hi Eran, 
Hi all, 

I briefly browsed through the -08 version of the draft to figure out
what could be written about extensibility. Here are a few thoughts:

- Client Profiles 

This is probably the most important item were people will want to write
extensions for. Currently, we have the following onces in the document: 
  1) Web Server
  2) User Agent
  3) Native Application
  4) Autonomous
  Note that the actual profile identifiers aren't clearly listed in the
document at the moment (or are inconsistent, such as "user_agent" and
"user-agent" for the user agent profile). 

We would want IANA to register them and then we need to list under what
conditions new profiles can be added, or existing onces updated/deleted.
RFC 5226 defines some typical policies, see
http://tools.ietf.org/html/rfc5226. 
We probably want the policy "RFC Required". When people write new
profiles we want them to provide a description about the use case, maybe
an example, we want them to discuss security, and  we definitely want to
ensure that the overall write is consistent with the base specification
(such as with the registry parameters it defines). The reviews would
ensure that existing profile do not in fact already provide the
functionality of the newly defined profile. Note that "RFC Required"
does not require a Standards Track RFC; an Informational or an
Experimental RFC is already sufficient. Those are less difficult to get
published but they still provide a stable reference. 

I would argue that we do not want new profiles to update existing onces
(unless they just informative changes or clarifications), in the sense
that they use the same profile name but with a modified semantic.
Instead, an updated profile would still define a new profile name and
would as such be different. I believe depreciating an existing entry
makes sense while deleting one does not. 

An open question might be whether there is a possibility for an
extension (other than a new profile) to define an optional parameter
that may get used with an existing profile. Note that at the moment
there is no registry for parameters.

- Scope 

The scope parameter is used in various places throught the document,
such as Section 3. Currently, the description does not indicate whether
there is a plan to have some standardized parameters with well-defined
semantic. Here is the current text for the scope parameter: 

"
   scope
         OPTIONAL.  The scope of the access request expressed as a list
         of space-delimited strings.  The value of the "scope" parameter
         is defined by the authorization server.  If the value contains
         multiple space-delimited strings, their order does not matter,
         and each string adds an additional access range to the
         requested scope.
"

Do folks think it would be useful to have standardized values? 

If the answer is "yes", then it would be useful to differentiate the
standardized values from those values that are purely defined locally by
the authorization server. 

- Error Codes 

The document lists error codes in Section 3.1 and Section 4.3. I suspect
that they are not from the same pool of error codes.  

My question is whether some of the error codes are very specific to the
profiles themselves or rather generic in nature.

- Grant Type

The Grant Type (grant_type) is described in Section 4. Currently, there
are 5 values defines ("authorization_code", "user_basic_credentials",
"assertion", "refresh_token", "none") and I assume that the list should
be extensible (even though the text currently says something else at the
moment). 

Are there specific requirements that must be met in order to register
new grant types? 

- Assertion Type 

Section 4.1.3 defines the assertion type ("assertion_type"). The text
indicates that the content is an absolute URI and as such it is a bit
different to the other value encodings we have seen previously.
Nevertheless, the question is whether some folks want to write
standardized templates for assertions, such as a specific form of SAML
assertion. This could help interoperability a lot, I believe. The
solution is still to have a URI but to define an IANA managed space for
IETF standardized assertion types. Such a style is btw common.

Do I miss something else? 

Ciao
Hannes

---

From: Dick Hardt <[email-masked]>
Date: Wed, 23 Jun 2010 09:02:27 -0700

> Do folks think it would be useful to have standardized values? 

Not at this time. The semantics of scope are all over the place. If standardized, people will feel they need to pick one that is close to what they want, but is not exactly what they mean. I think it is better for the AS to define what they mean by a scope and give it a name that makes sense in that context.

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 23 Jun 2010 14:26:54 -0400

Thanks Hannes. Great list of to-do items for the WG :)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Wednesday, June 23, 2010 2:08 AM
>

Is the plan to have a separate document for each profile?  I'm assuming 
that we are all waiting for the draft-oath-v2 to stabilize (ps. it's 
gone from version 05 to 08 in a matter of 2-3 weeks, and now going to 
09). We need to lock-down, I think. Need to distinguish between 
major/significant changes to minor/typo fixes.

> there is no registry for parameters.

It depends on what meaning of "profile" and "extension". If the optional 
parameter is used in one of the profiles (use-cases) only, then it 
should not be place into the core draft-oauth-v2. If the optional 
parameter ends-up being used in all the profiles (use-cases), then add 
it to the core. I think this is where you draw the line (otherwise all 
sorts of weird and wonderful parameters ends-up in the core draft).

/thomas/

---

From: Lukas Rosenstock <[email-masked]>
Date: Thu, 24 Jun 2010 09:49:05 +0200

Wasn't there some concensus that URIs would be good for scope? They
have "in-built namespacing" ...

Lukas

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 24 Jun 2010 13:58:09 +0300

The question is whether one would ever want to have a standardized semantic for the scope parameter. 
If the answer to that question is "no" then it does not matter what the format is. It can well be a list of  space-delimited strings (as it is currently defined). 

An evironment specific semantic works well in cases where entity X sets the value and later it receives the value again. Only entity X needs to understand what it means.

In some environments the use case is slightly different, namely entity X and entity Y are from the same organization and agree on the semantic. Usage of OAuth within an enterprise might be such a case. 

Now, the usage of the scope parameter is, however, a bit different in the spec. Section 4, for example, describes how a client obtains an access token. How does the client know what scope parameters to set and what the semantic is?

Ciao
Hannes

> From: ext Lukas Rosenstock [mailto:[email-masked]] 
> Sent: Thursday, June 24, 2010 10:49 AM
> To: Dick Hardt
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG
> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?
> 
> > Not at this time. The semantics of scope are all over the 
> place. If standardized, people will feel they need to pick 
> one that is close to what they want, but is not exactly what 
> they mean. I think it is better for the AS to define what 
> they mean by a scope and give it a name that makes sense in 
> that context.
> >
> >>

---

From: Justin Richer <[email-masked]>
Date: Thu, 24 Jun 2010 10:02:12 -0400

I recall there being consensus on the space delimiter to make it so that
URIs could be used easily as scope parameters. I know that I,
personally, would rather have keywords in our implementation than URIs,
so I'm very much in favor of keeping it unspecified.

 -- justin

On Thu, 2010-06-24 at 03:49 -0400, Lukas Rosenstock wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Thu, 24 Jun 2010 09:31:00 -0700

When the API is standardized, it makes sense for the scope parameter to be standardized. If the API is unique to the PR, then the scope will also be unique. There may be concepts that are similar across unique APIs, but there will be nuances that are important to be aware of.

To answer your question about where the scope parameter come from, documentation for the API.

-- Dick

---

From: "William Mills" <[email-masked]>
Date: Thu, 24 Jun 2010 10:15:06 -0700

I'm in favor of having a spaces separated list of tokens.  The only case I can think of where the client needs to handle the scope as anything other than opaque is when it is accessing multiple services.  To reduce the numebr of login events the client will have to poll all the endpoints it wants to access and get all the scopes advertized by them and submit them all, and once it has them it needs to submit all of them in it's auth request, so we need something that's easy for the client to put together.

-bill

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Thursday, June 24, 2010 3:58 AM
> To: ext Lukas Rosenstock; Dick Hardt
> Cc: OAuth WG
> The question is whether one would ever want to have a 
> standardized semantic for the scope parameter. 
> If the answer to that question is "no" then it does not 
> matter what the format is. It can well be a list of  
> space-delimited strings (as it is currently defined). 
> 
> An evironment specific semantic works well in cases where 
> entity X sets the value and later it receives the value 
> again. Only entity X needs to understand what it means.
> 
> In some environments the use case is slightly different, 
> namely entity X and entity Y are from the same organization 
> and agree on the semantic. Usage of OAuth within an 
> enterprise might be such a case. 
> 
> Now, the usage of the scope parameter is, however, a bit 
> different in the spec. Section 4, for example, describes how 
> a client obtains an access token. How does the client know 
> what scope parameters to set and what the semantic is?
> 
> Ciao
> Hannes
> 
> one that is 
> > close to what they want, but is not exactly what they mean. 
> I think it 
> > is better for the AS to define what they mean by a scope 
> and give it a 
> > name that makes sense in that context.
> > >
> > >>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 25 Jun 2010 10:59:50 +0300

Dick pointed me to the Facebook API on how scope is used. 
The main page is here: 
http://developers.facebook.com/docs/authentication/

It describes the basic functionality and also lists an example: 

"
https://graph.facebook.com/oauth/authorize?
    client_id=...&
    redirect_uri=http://www.example.com/callback&
    scope=user_photos,user_videos,publish_stream
"

The values of the scope parameter are then explained here: 
http://developers.facebook.com/docs/authentication/permissions

Example: user_photos ... Provides access to the photos the user has uploaded

I think it provides a good example that the scope values are not opaque.  
Opaque (in this context) means that only the entity creating it needs to understand it and nobody else. Here the client needs to understand and set them. 

However, one could argue that the scope values are already bound to the specific entity the client requests to obtain the assertion from. In this specific case it would be "https://graph.facebook.com". 

To respond to the statement Dick made about having standardized values later there would still be the need to decide about the structure of the values now. One possibility is to just add a prefix for standardized values that are not allowed to be used in other cases, such as "std:". 

Ciao
Hannes

> From: ext William Mills [mailto:[email-masked]] 
> Sent: Thursday, June 24, 2010 8:15 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas 
> Rosenstock; Dick Hardt
> Cc: OAuth WG
> Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?
> 
> I'm in favor of having a spaces separated list of tokens.  
> The only case I can think of where the client needs to handle 
> the scope as anything other than opaque is when it is 
> accessing multiple services.  To reduce the numebr of login 
> events the client will have to poll all the endpoints it 
> wants to access and get all the scopes advertized by them and 
> submit them all, and once it has them it needs to submit all 
> of them in it's auth request, so we need something that's 
> easy for the client to put together.
> 
> 
> -bill
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 25 Jun 2010 10:26:50 -0400

I don't agree: these values are still opaque to OAuth. They're not
opaque to the client and server, they're part of the API. But the client
-- and by "client" here I mean the whole client application, not just
the OAuth client -- needs to know what they're for. In the same fashion,
the client needs to know where to send the tokens to get user photos. 

What's more important is that the functionality around the OAuth
transaction be transparent to any OAuth implementation or library. I
should be able to build a Facebook client on top of any compliant OAuth
library. Well, once Facebook is compliant of course. ;) But that client
should be able to call oauthReq.setScopes("user_photos", "user_videos",
"publish_stream") from a library and have it passed through the system
as expected. 

 -- Justin

On Fri, 2010-06-25 at 03:59 -0400, Tschofenig, Hannes (NSN - FI/Espoo)

---

From: Blaine Cook <[email-masked]>
Date: Fri, 25 Jun 2010 15:52:44 +0100

I agree with Dick that the scope should remain out of scope for OAuth.
;-) Having a shared parameter here gives the illusion of
interoperability, but because there's no common understanding of
permissible scopes, there's no way to guarantee that any given
client-server pair could expect to produce predictable outcomes.

Furthermore, limiting the format of the scope prematurely means that
we give up on a whole set of possibilities before we've even had a
chance to see what those possibilities are. For example, YQL might
want to allow a scope to be defined like "SELECT * FROM flickr" or
something similar. Maybe scope is implicit in assertions, or even
explicit. Scope might be tied to the degree to which the requesting
and/or granting parties are trusted by the service provider.

If there were a compelling story about how scope is supposed to
realistically achieve greater interoperability, it might be worthwhile
for us to consider it. In the meantime, though, I think it just
represents the same featuritis drive that got us an under-specified
(and more harmful than helpful) version parameter in OAuth 1.0.

b.

---

From: Dick Hardt <[email-masked]>
Date: Fri, 25 Jun 2010 08:49:50 -0700

To clarify, the goal is to reserve a namespace for future use so that near term implementations won't collide?

I expect the standardization of scope values to not be in OAuth, but in standardized APIs that use OAuth, so a namespace mechanism that differentiates between a standardized scope and an implementation specific scope may be useful.

From what I have gathered, implementors are leaning towards simple strings rather than URIs to declare scope. Perhaps reserving the ":" character from being in a scope string unless the scope prefix has been registered with IANA?

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Fri, 25 Jun 2010 08:54:31 -0700

Glad to see people agreeing with me. I don't think Hannes was disagreeing with me though. :)

Per my response to Hannes, I think there is value in a small restriction on scope strings so that we have a reserved format for the future.

-- Dick

---

From: Luke Shepard <[email-masked]>
Date: Fri, 25 Jun 2010 10:53:52 -0700

Agree.

Dick- just to clarify, you mean a restriction that they be space-delimited opaque strings as defined in the latest draft? Or something different?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Jun 2010 10:59:50 -0700

> Sent: Tuesday, June 22, 2010 11:08 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Extensibility for OAuth?
> 
> Hi Eran,
> Hi all,
> 
> I briefly browsed through the -08 version of the draft to figure out what
> could be written about extensibility. Here are a few thoughts:
> 
> - Client Profiles
> 
>   Note that the actual profile identifiers aren't clearly listed in the document
> at the moment (or are inconsistent, such as "user_agent" and "user-agent"
> for the user agent profile).

Profiles are not normative language, they are just examples of the authorization and token endpoints can be used (profiled) for particular use cases (the most common ones). This is why this has been moved to the introduction. Instead, the spec now talks about grant types, providing three primary types (user basic credentials, authorization code obtained from the authorization endpoint, and assertion). The assertion type is the generic extension point using a URI-formatted assertion type (which does not require a registry).

I would rather limit the ability to extend the two endpoints beyond their current architecture, and instead, allow others to specify new endpoints (e.g. a device endpoint for getting an authorization code without using browser redirection) that work in addition to the token endpoint (using an existing grant type or assertion).

> profiles we want them to provide a description about the use case, maybe an
> example, we want them to discuss security, and  we definitely want to
> ensure that the overall write is consistent with the base specification (such as
> with the registry parameters it defines). The reviews would ensure that
> existing profile do not in fact already provide the functionality of the newly
> defined profile. Note that "RFC Required"
> does not require a Standards Track RFC; an Informational or an Experimental
> RFC is already sufficient. Those are less difficult to get published but they still
> provide a stable reference.

I think Specification Required is better for most registries.

> - Error Codes
> 
> The document lists error codes in Section 3.1 and Section 4.3. I suspect that
> they are not from the same pool of error codes.
> 

I'm working to clean up errors in -09.

> - Grant Type
> 
> The Grant Type (grant_type) is described in Section 4. Currently, there are 5
> values defines ("authorization_code", "user_basic_credentials", "assertion",
> "refresh_token", "none") and I assume that the list should be extensible
> (even though the text currently says something else at the moment).
> 
> Are there specific requirements that must be met in order to register new
> grant types?

I would rather not allow for new grant types. I think the assertion type offers as much extensibility as needed. However, I am going to propose we allow extension parameters to both endpoints.

> indicates that the content is an absolute URI and as such it is a bit different to
> the other value encodings we have seen previously.
> assertion. This could help interoperability a lot, I believe. The solution is still
> to have a URI but to define an IANA managed space for IETF standardized
> assertion types. Such a style is btw common.

I am not sure this is needed. URIs provide name collision protection. Beyond that, people should write specs as needed.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Jun 2010 11:11:20 -0700

The interop value of the current proposal is simple:

- defines how multiple scopes are to be expressed (order doesn't matter, space delimited)
- provides an easy way to express the required scope when rejected a protected resource request
- allows clients the ability to combine scopes (known and discovered) without additional server-specific logic

I think this is enough value to define an internal structure to the scope string beyond just a blob. The current proposal doesn't prevent the YQL example you provided, just that it needs to be encoded to replace the spaces with something else (since space delimited order does not matter).

We want to keep scope underspecified enough to allow the level of customization currently expressed by the different vendors represented here. But we also want to make sure that defining interop scopes is well understood and simple as we already have a few use cases for it (e.g. OpenID Connect, Portable Contacts).

EHL

> Of Blaine Cook
> Sent: Friday, June 25, 2010 7:53 AM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: OAuth WG
> ;-) Having a shared parameter here gives the illusion of interoperability, but
> because there's no common understanding of permissible scopes, there's no
> way to guarantee that any given client-server pair could expect to produce
> predictable outcomes.
> 
> Furthermore, limiting the format of the scope prematurely means that we
> give up on a whole set of possibilities before we've even had a chance to see
> what those possibilities are. For example, YQL might want to allow a scope to
> be defined like "SELECT * FROM flickr" or something similar. Maybe scope is
> implicit in assertions, or even explicit. Scope might be tied to the degree to
> which the requesting and/or granting parties are trusted by the service
> provider.
> 
> If there were a compelling story about how scope is supposed to realistically
> achieve greater interoperability, it might be worthwhile for us to consider it.
> In the meantime, though, I think it just represents the same featuritis drive
> that got us an under-specified (and more harmful than helpful) version
> parameter in OAuth 1.0.
> 
> b.
> 
> > Opaque (in this context) means that only the entity creating it needs to
> understand it and nobody else. Here the client needs to understand and set
> them.
> >
> > However, one could argue that the scope values are already bound to the
> specific entity the client requests to obtain the assertion from. In this specific
> case it would be "https://graph.facebook.com".
> >
> > To respond to the statement Dick made about having standardized values
> later there would still be the need to decide about the structure of the
> values now. One possibility is to just add a prefix for standardized values that
> are not allowed to be used in other cases, such as "std:".
> >
> > Ciao
> > Hannes
> >
> >
> >> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas Rosenstock; Dick
> >> Hardt
> >> Cc: OAuth WG
> >> The only case I can think of where the client needs to handle the
> >> scope as anything other than opaque is when it is accessing multiple
> >> services.  To reduce the numebr of login events the client will have
> >> to poll all the endpoints it wants to access and get all the scopes
> >> advertized by them and submit them all, and once it has them it needs
> >> to submit all of them in it's auth request, so we need something
> >> that's easy for the client to put together.
> >>
> >>
> >> -bill
> >>
> >> > From: [email-masked] [mailto:[email-masked]] On
> >> > Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> >> > If the answer to that question is "no" then it does not matter what
> >> > the format is. It can well be a list of space-delimited strings (as
> >> > it is currently defined).
> >> >
> >> > An evironment specific semantic works well in cases where entity X
> >> > sets the value and later it receives the value again. Only entity X
> >> > needs to understand what it means.
> >> >
> >> > In some environments the use case is slightly different, namely
> >> > entity X and entity Y are from the same organization and agree on
> >> > the semantic. Usage of OAuth within an enterprise might be such a
> >> > case.
> >> >
> >> > Now, the usage of the scope parameter is, however, a bit different
> >> > in the spec. Section 4, for example, describes how a client obtains
> >> > an access token. How does the client know what scope parameters to
> >> > set and what the semantic is?
> >> >
> >> > Ciao
> >> > Hannes
> >> >

---

From: Dick Hardt <[email-masked]>
Date: Fri, 25 Jun 2010 11:12:55 -0700

Would you elaborate on your reasons here? Do you think we have enumerated all the possibilities?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Jun 2010 11:14:53 -0700

I like the idea of an extensibility mechanism for standard scopes, but I am not sure I like the idea of a prefix or reserved characters. Using URIs as scope values was a requirement (and something that is currently deployed by Google). We defined space-delimited to make simple strings and URIs possible as values.

My question is, why isn't URIs enough for standard scopes? Define simple strings as server-specific and allow URIs to be used in standards (which will solve potential name collisions). It might make standard scopes a bit less cool but that's not a technical argument. I also think scopes are likely to be extended a lot more than other extension types and would like to keep the process as light as possible (i.e. no registration at all).

EHL

> Of Dick Hardt
> Sent: Friday, June 25, 2010 8:50 AM
> I expect the standardization of scope values to not be in OAuth, but in
> standardized APIs that use OAuth, so a namespace mechanism that
> differentiates between a standardized scope and an implementation specific
> scope may be useful.
> 
> From what I have gathered, implementors are leaning towards simple strings
> rather than URIs to declare scope. Perhaps reserving the ":" character from
> being in a scope string unless the scope prefix has been registered with
> IANA?
> 
> -- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Jun 2010 11:18:12 -0700

I think the two endpoints are currently well defined. For example, the token endpoint always takes an access grant and turns it into an access token with optional refresh token. To "extend" it to say, register new clients dynamically, is a bad thing. But adding a new parameter (such as language) is a good thing to support, and by requiring review, only parameters that don't change the overall design will be approved.

EHL

> From: Dick Hardt [mailto:[email-masked]]
> Sent: Friday, June 25, 2010 11:13 AM
> To: Eran Hammer-Lahav
> Subject: Re: [OAUTH-WG] Extensibility for OAuth?
> 
> > I would rather limit the ability to extend the two endpoints beyond their
> current architecture, and instead, allow others to specify new endpoints (e.g.
> a device endpoint for getting an authorization code without using browser
> redirection) that work in addition to the token endpoint (using an existing
> grant type or assertion).

---

From: Dick Hardt <[email-masked]>
Date: Fri, 25 Jun 2010 11:18:42 -0700

I'm ok with that if we provide some guidance in the spec to implementors that recommends the use of URIs for scopes they expect to be standardized.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Jun 2010 11:21:27 -0700

That's coming in -09.

EHL

> Sent: Friday, June 25, 2010 11:19 AM
> To: Eran Hammer-Lahav
> I'm ok with that if we provide some guidance in the spec to implementors
> that recommends the use of URIs for scopes they expect to be standardized.
> 
> > I like the idea of an extensibility mechanism for standard scopes, but I am
> not sure I like the idea of a prefix or reserved characters. Using URIs as scope
> values was a requirement (and something that is currently deployed by
> Google). We defined space-delimited to make simple strings and URIs
> possible as values.
> >
> > My question is, why isn't URIs enough for standard scopes? Define simple
> strings as server-specific and allow URIs to be used in standards (which will
> solve potential name collisions). It might make standard scopes a bit less cool
> but that's not a technical argument. I also think scopes are likely to be
> extended a lot more than other extension types and would like to keep the
> process as light as possible (i.e. no registration at all).
> >
> > EHL
> >
> >> Behalf Of Dick Hardt
> >> I expect the standardization of scope values to not be in OAuth, but
> >> in standardized APIs that use OAuth, so a namespace mechanism that
> >> differentiates between a standardized scope and an implementation
> >> specific scope may be useful.
> >>
> >> From what I have gathered, implementors are leaning towards simple
> >> strings rather than URIs to declare scope. Perhaps reserving the ":"
> >> character from being in a scope string unless the scope prefix has
> >> been registered with IANA?
> >>
> >> -- Dick
> >> understand it and nobody else. Here the client needs to understand
> >> and set them.
> >>>
> >> specific entity the client requests to obtain the assertion from. In
> >> this specific case it would be "https://graph.facebook.com".
> >>>
> >> later there would still be the need to decide about the structure of
> >> the values now. One possibility is to just add a prefix for
> >> standardized values that are not allowed to be used in other cases, such
> as "std:".
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>>
> >>>> scope as anything other than opaque is when it is accessing
> >>>> multiple services.  To reduce the numebr of login events the client
> >>>> will have to poll all the endpoints it wants to access and get all
> >>>> the scopes advertized by them and submit them all, and once it has
> >>>> them it needs to submit all of them in it's auth request, so we
> >>>> need something that's easy for the client to put together.
> >>>>
> >>>>
> >>>> -bill
> >>>>
> >>>>> If the answer to that question is "no" then it does not matter
> >>>>> what the format is. It can well be a list of space-delimited
> >>>>> strings (as it is currently defined).
> >>>>>
> >>>>> sets the value and later it receives the value again. Only entity
> >>>>> X needs to understand what it means.
> >>>>>
> >>>>> in the spec. Section 4, for example, describes how a client
> >>>>> obtains an access token. How does the client know what scope
> >>>>> parameters to set and what the semantic is?
> >>>>>
> >>>>> Ciao
> >>>>> Hannes
> >>>>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 25 Jun 2010 11:22:13 -0700

Agree that if it is a different kind of function, than a new end point is a good thing.

I'm not understanding the review process below in your example. Would adding language parameters not be an extension? Would that need to be a change to the spec or a new spec?
.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Jun 2010 11:34:37 -0700

The language parameter will need a new spec (doesn't have to be an RFC, but that's open to debate), and will register the parameter in the IANA registry for that endpoint. In order to register, the request will be posted to a public list and a designated expert(s) will review it in a timely manner. If there is consensus, the request will be approved. By seeking consensus for the registration, the community will get to decide if the proposal does not change the meaning of the endpoint.

So:

1. write a new spec
2. request new parameter registration
3. discuss the use case and proposal on a public list (special for this)
4. get designated expert review
5. get IANA to register

The whole thing can be as fast as 2-3 weeks.

EHL

> Sent: Friday, June 25, 2010 11:22 AM
> To: Eran Hammer-Lahav
> I'm not understanding the review process below in your example. Would
> adding language parameters not be an extension? Would that need to be a
> change to the spec or a new spec?
> .
> > I think the two endpoints are currently well defined. For example, the
> token endpoint always takes an access grant and turns it into an access token
> with optional refresh token. To "extend" it to say, register new clients
> dynamically, is a bad thing. But adding a new parameter (such as language) is
> a good thing to support, and by requiring review, only parameters that don't
> change the overall design will be approved.
> >
> > EHL
> >
> >> redirection) that work in addition to the token endpoint (using an
> >> existing grant type or assertion).
> >

---

From: Justin Hart <[email-masked]>
Date: Fri, 25 Jun 2010 12:18:41 -0700

+1 towards space-seperated strings.  It seems like every server is going to have diverging requirements on scopes, so anything more will be awfully hard for everyone to agree on.
----
-- Justin Hart
-- [email-masked]