[WG-UMA] A few spec questions
Anganes, Amanda L
Hi, Umanitarians!
I have a few questions about the current spec draft for uma-core:
1) Sections 2.4.1 and 2.4.2 each have a line that says
“… descriptions MAY contain extension properties that are not defined in this specification. The names of extension properties MUST consist of a fully qualified URL or begin with "x-" or "X-".”
What is the purpose of the “x-“ or “X-“ prefix? My understanding is that this is sometimes used to avoid collisions, although it really just pushes the collision problem into the x-space. The OAuth2 spec has taken the approach of using short names for all parameters described in the document, and requiring extension parameters to either be registered in a central registry or be fully-qualified URI’s.
2) What is the purpose of defining the new token type, “Artifact” (described in Section 1.5)? It is not well-defined in the spec, other than to say that it is an “opaque token string”. Why not use the existing OAuth 2 Bearer token type instead of defining a new one?
3) Section 3.3: What is the purpose of including the requester’s IP address to be included in token status request? The last sentence in paragraph 2 says it is “advisory only” – does this mean that its inclusion in the request is a suggestion (ie, “MAY include the IP address”)?
Thanks,
Amanda Anganes
Info Sys Engineer, G061
The MITRE Corporation
Thomas Hardjono
> From: wg-uma-...@kantarainitiative.org
> [mailto:wg-uma-...@kantarainitiative.org] On Behalf Of Anganes,
> Amanda L
> Sent: Thursday, February 02, 2012 2:48 PM
> To: wg-...@kantarainitiative.org
> Subject: [WG-UMA] A few spec questions
>
> Hi, Umanitarians!
>
> I have a few questions about the current spec draft for uma-core:
>
> 1) Sections 2.4.1 and 2.4.2 each have a line that says ".
descriptions
> MAY contain extension properties that are not defined in this
> specification. The names of extension properties MUST consist of a
> fully qualified URL or begin with "x-" or "X-"."
> What is the purpose of the "x-" or "X-" prefix? My understanding is
> that this is sometimes used to avoid collisions, although it really
> just pushes the collision problem into the x-space. The OAuth2 spec
has
> taken the approach of using short names for all parameters described
in
> the document, and requiring extension parameters to either be
> registered in a central registry or be fully-qualified URI's.
Hmm, this may be a left-over from previous versions of the draft. Did
we still want this?
> 2) What is the purpose of defining the new token type, "Artifact"
> (described in Section 1.5)? It is not well-defined in the spec,
other
> than to say that it is an "opaque token string". Why not use the
> existing OAuth 2 Bearer token type instead of defining a new one?
This related to Issue #30.
https://github.com/xmlgrrl/UMA-Specifications/issues/30
We decided to keep the token as an opaque structure so that the Host
does not need to peek (cannot see into) the token. The Host would be
dependent on the AM for token validation. In this way, the AM has the
freedom to choose the token structure (most likely in fact to be
OAuth2.0 bearer token) and which attributes to encrypt/sign as seen
fit by the AM. However, we don't necessarily what to be tied down to
just the OAuth2.0 bearer token going into the future.
> 3) Section 3.3: What is the purpose of including the requester's IP
> address to be included in token status request? The last sentence in
> paragraph 2 says it is "advisory only" - does this mean that its
> inclusion in the request is a suggestion (ie, "MAY include the IP
> address")?
I might have forgotten the discussion, but I believe this is to
address the situation where the Requester is using a different IP
address (to access the resource) from when he/she initially requested
the access token. However, I believe this has little security value.
/thomas/
_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler
I recall that we deliberately chose this method of extension, on Paul B's recommendation, and I'm still pretty happy with it. We'd need a registry in the fullness of time if the external world didn't self-organize around the x- convention and needed to add properties like mad to all our little formats, but a registry isn't strictly required. The important thing is that we reserve all non-URL non-"x-" strings for ourselves to give a clear field.
I was hoping we'd captured our lovely rationale for this decision in our minutes, but I just find an outright agreement to use this method. Paul, do you want to say more?
>
>
>> 2) What is the purpose of defining the new token type, "Artifact"
>> (described in Section 1.5)? It is not well-defined in the spec,
> other
>> than to say that it is an "opaque token string". Why not use the
>> existing OAuth 2 Bearer token type instead of defining a new one?
>
> This related to Issue #30.
> https://github.com/xmlgrrl/UMA-Specifications/issues/30
>
> We decided to keep the token as an opaque structure so that the Host
> does not need to peek (cannot see into) the token. The Host would be
> dependent on the AM for token validation. In this way, the AM has the
> freedom to choose the token structure (most likely in fact to be
> OAuth2.0 bearer token) and which attributes to encrypt/sign as seen
> fit by the AM. However, we don't necessarily what to be tied down to
> just the OAuth2.0 bearer token going into the future.
Thomas identifies exactly the semantic that "artifact" conveys: you must use the token status request to validate it. Are there aspects of the OAuth2 bearer token that would tie us down too aggressively, or alternatively be helpful to us? If we consider a switch, what are the benefits/costs?
>
>
>> 3) Section 3.3: What is the purpose of including the requester's IP
>> address to be included in token status request? The last sentence in
>> paragraph 2 says it is "advisory only" - does this mean that its
>> inclusion in the request is a suggestion (ie, "MAY include the IP
>> address")?
>
> I might have forgotten the discussion, but I believe this is to
> address the situation where the Requester is using a different IP
> address (to access the resource) from when he/she initially requested
> the access token. However, I believe this has little security value.
George originally suggested this as additional context to help the AM decide more accurately whether the requester is for real. But it does feel a bit messy; it sort of gets UMA into the risk-based authentication/authorization game.
Actually, this reminds me of a number of aspects of "business use cases" that have been brought up to me recently. Making authorization decisions is serious business, and often a variety of system-state, transaction-context, and user-attribute data needs to be brought into play. UMA's claims-based authorization approach answers the last of these, but the first two aren't addressed in our model to date. Should they be? If so, who is responsible for them and who needs to convey what to whom?
Eve
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
Justin Richer
post did start from a conversation we had last week.
If that's the case, then just constrain all short names to those defined
in the document and require fully qualified URIs (not URLs) for all
extensions. As you say, if there's a clamor for short names, then you
can set up a registry in the future to prevent overloading. The "x-"
notation is a red herring -- it keeps new short names from conflicting
with terms in the core spec, something that's not likely to happen
anyway, while providing absolutely no protection against independent
extensions conflicting with each other.
>>> 2) What is the purpose of defining the new token type, "Artifact"
>>> (described in Section 1.5)? It is not well-defined in the spec,
>> other
>>> than to say that it is an "opaque token string". Why not use the
>>> existing OAuth 2 Bearer token type instead of defining a new one?
>> This related to Issue #30.
>> https://github.com/xmlgrrl/UMA-Specifications/issues/30
>>
>> We decided to keep the token as an opaque structure so that the Host
>> does not need to peek (cannot see into) the token. The Host would be
>> dependent on the AM for token validation. In this way, the AM has the
>> freedom to choose the token structure (most likely in fact to be
>> OAuth2.0 bearer token) and which attributes to encrypt/sign as seen
>> fit by the AM. However, we don't necessarily what to be tied down to
>> just the OAuth2.0 bearer token going into the future.
> Thomas identifies exactly the semantic that "artifact" conveys: you must use the token status request to validate it. Are there aspects of the OAuth2 bearer token that would tie us down too aggressively, or alternatively be helpful to us? If we consider a switch, what are the benefits/costs?
The Bearer spec says nothing about what the PR does with the token once
it gets it, so you can still require the PR call the API itself. The
important thing is that you're *treating* it as a Bearer token, since
the PR *must* pass the entire token off to the AM in order to get the
thumbs up or thumbs down. If it were a token with a private component,
like a MAC token, you couldn't do this delegated call with any assurance.
As it stands right now, UMA seems to be saying that it's a new token
flavor without defining what's different about any of these pieces. For
instance, an example Bearer token (from the spec) comes back as:
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
}
UMA's use of the term "token type" with a value of "artifact" implies
but does not fully specify that the return from the server would look like:
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"artifact",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
}
Since the "token_type" is communicated only to the *client* and not the
PR, the token_type returned here makes no difference to the PR. Since
the PR is the only component whose behavior has to change with the new
token type, and the PR will never know there's a different token type in
play, and the "artifact" token is in every other way identical to the
Bearer token, I see no reason for UMA to deviate from the Bearer
behavior. By just calling it an OAuth2 Bearer token, you can use all of
the off-the-shelf definitions about the Bearer token, from the structure
that the AS returns from the token endpoint to the authz
header/parameter passed into the PR.
>>> 3) Section 3.3: What is the purpose of including the requester's IP
>>> address to be included in token status request? The last sentence in
>>> paragraph 2 says it is "advisory only" - does this mean that its
>>> inclusion in the request is a suggestion (ie, "MAY include the IP
>>> address")?
>> I might have forgotten the discussion, but I believe this is to
>> address the situation where the Requester is using a different IP
>> address (to access the resource) from when he/she initially requested
>> the access token. However, I believe this has little security value.
>
> George originally suggested this as additional context to help the AM decide more accurately whether the requester is for real. But it does feel a bit messy; it sort of gets UMA into the risk-based authentication/authorization game.
>
> Actually, this reminds me of a number of aspects of "business use cases" that have been brought up to me recently. Making authorization decisions is serious business, and often a variety of system-state, transaction-context, and user-attribute data needs to be brought into play. UMA's claims-based authorization approach answers the last of these, but the first two aren't addressed in our model to date. Should they be? If so, who is responsible for them and who needs to convey what to whom?
>
You're spot on -- there's a *lot* of context that can go into making
these decisions. Instead of popping in the IP address, perhaps UMA
should have a structured slot for the PR to toss a bunch of "helpful
info" back to the AM? I'm not sure what this would look like, and I'm
not sure how much of this structure should be defined by UMA and how
much by convention between the PR and AM. But since the AM is allowed to
ignore all of that when making its decision, this could all be moot.
-- Justin
Eve Maler
We have had examples in the SMART team of people inventing extension properties using x-, but of course if that option weren't available, they could have picked something like http://smartam.org/whatever (or a URN for that metter). So, let's try and run a decision to ground in Thursday's meeting. Options I'm seeing so far:
a) Status quo throughout
b) Keep the same throughout but mention "URIs" instead of "URLs"
c) Switch to "URIs" and remove all the x-/X- options throughout
Any others we should consider?
Are you suggesting that the token status request in UMA should return the structures above? Because we've defined what the "token status" should look like, and it's pretty UMA-specific (using our permission construct, which is based on our scope construct, which is much more specific than in OAuth).
>
>>>> 3) Section 3.3: What is the purpose of including the requester's IP
>>>> address to be included in token status request? The last sentence in
>>>> paragraph 2 says it is "advisory only" - does this mean that its
>>>> inclusion in the request is a suggestion (ie, "MAY include the IP
>>>> address")?
>>> I might have forgotten the discussion, but I believe this is to
>>> address the situation where the Requester is using a different IP
>>> address (to access the resource) from when he/she initially requested
>>> the access token. However, I believe this has little security value.
>>
>> George originally suggested this as additional context to help the AM decide more accurately whether the requester is for real. But it does feel a bit messy; it sort of gets UMA into the risk-based authentication/authorization game.
>>
>> Actually, this reminds me of a number of aspects of "business use cases" that have been brought up to me recently. Making authorization decisions is serious business, and often a variety of system-state, transaction-context, and user-attribute data needs to be brought into play. UMA's claims-based authorization approach answers the last of these, but the first two aren't addressed in our model to date. Should they be? If so, who is responsible for them and who needs to convey what to whom?
>>
> You're spot on -- there's a *lot* of context that can go into making
> these decisions. Instead of popping in the IP address, perhaps UMA
> should have a structured slot for the PR to toss a bunch of "helpful
> info" back to the AM? I'm not sure what this would look like, and I'm
> not sure how much of this structure should be defined by UMA and how
> much by convention between the PR and AM. But since the AM is allowed to
> ignore all of that when making its decision, this could all be moot.
We could do this, if we assume that it's the AM responsible for assessing these factors. The topic has come up more in conversation (for me, at least) around "business" use cases rather than "user-centric" use cases; should we gather more input and experience in those sorts of use cases, and in the meantime just remove the IP address hint?
Eve
_______________________________________________
Richer, Justin P.
My vote, if it wasn't clear above, is "c".
No, these are the responses from the Token Endpoint as required by OAuth2. The Token Status can still return whatever UMA-specific structure that it wants, but what I'm suggesting is that the Client get a plain old Bearer token from the Token Endpoint, hand that Bearer token to the Host using plain old Bearer token syntax, and then the Host turns around and makes the UMA-specific Token Status call and gets back whatever structure it needs. There is no need or benefit for a new token type for the client in this case.
>>
>>>>> 3) Section 3.3: What is the purpose of including the requester's IP
>>>>> address to be included in token status request? The last sentence in
>>>>> paragraph 2 says it is "advisory only" - does this mean that its
>>>>> inclusion in the request is a suggestion (ie, "MAY include the IP
>>>>> address")?
>>>> I might have forgotten the discussion, but I believe this is to
>>>> address the situation where the Requester is using a different IP
>>>> address (to access the resource) from when he/she initially requested
>>>> the access token. However, I believe this has little security value.
>>>
>>> George originally suggested this as additional context to help the AM decide more accurately whether the requester is for real. But it does feel a bit messy; it sort of gets UMA into the risk-based authentication/authorization game.
>>>
>>> Actually, this reminds me of a number of aspects of "business use cases" that have been brought up to me recently. Making authorization decisions is serious business, and often a variety of system-state, transaction-context, and user-attribute data needs to be brought into play. UMA's claims-based authorization approach answers the last of these, but the first two aren't addressed in our model to date. Should they be? If so, who is responsible for them and who needs to convey what to whom?
>>>
>> You're spot on -- there's a *lot* of context that can go into making
>> these decisions. Instead of popping in the IP address, perhaps UMA
>> should have a structured slot for the PR to toss a bunch of "helpful
>> info" back to the AM? I'm not sure what this would look like, and I'm
>> not sure how much of this structure should be defined by UMA and how
>> much by convention between the PR and AM. But since the AM is allowed to
>> ignore all of that when making its decision, this could all be moot.
>
> We could do this, if we assume that it's the AM responsible for assessing these factors. The topic has come up more in conversation (for me, at least) around "business" use cases rather than "user-centric" use cases; should we gather more input and experience in those sorts of use cases, and in the meantime just remove the IP address hint?
I think this sounds reasonable -- might be a case of preemptive over engineering.
-- Justin
Thomas Hardjono
> -----Original Message-----
> From: wg-uma-...@kantarainitiative.org [mailto:wg-uma-
> bou...@kantarainitiative.org] On Behalf Of Richer, Justin P.
> Sent: Wednesday, February 08, 2012 10:33 AM
> To: Eve Maler
> Cc: <wg-...@kantarainitiative.org>
> Subject: Re: [WG-UMA] A few spec questions
>
> [snip]
This kinda makes sense. The Host speaks plain Oauth bearer token to
the Requester, but the Host speaks UMA when talking to the AM.
/thomas/