I'm fine with it being optional but I don't think it should be removed.
I have a use case where the actor_token is being used. In my use case
the "actor" represents a device making a token exchange between two
applications running on the device. It allows the AS to enforce a
binding such that only apps on the same device can exchange tokens.
Full details can be found on the OpenID Connect working group mailing list:
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180430/006733.html
Thanks,
George
On 5/17/18 8:10 AM, Bill Burke wrote:
My personal opinion is that I'm glad this actor stuff is optional.
For one, none of our users have asked for it and really only do simple
exchanges. Secondly, the rules for who can exchange what for what is
controlled and defined within our AS. Makes things a lot simpler on
the client. I kind of wish the actor stuff would be defined in a
separate specification. I don't see us implementing it unless users
start asking us to.
On Wed, May 16, 2018 at 6:11 PM, Brian Campbell
<bcampb...@pingidentity.com> wrote:
Well, it's already called the "actor claim" so the claimed part is kind of
implied. And "claimed actor claim" is a rather awkward. Really, all JWT
claims are "claimed something" but they don't include the "claimed" bit in
the name. RFC 7519, for example, defines the subject claim but not the
claimed subject claim.
On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.i...@free.fr> wrote:
Brian,
Eric said: "what is the RP supposed to do when they encounter it? This
seems kind of under specified".
After reading your explanations below, it looks like the RP can do
anything he wants with the "actor".
It is a "claimed actor" and, if we keep the concept, it should be called
as such. Such a claim cannot be verified.
A RP could copy and paste that claim in an audit log. No standard action
related to the content of such a claim
can be specified in the spec. If the content of a "claimed actor" is used
by the RP, it should be only used as an hint
and thus be subject to other verifications which are not specified in this
specification.
Denis
Eric, I realize you weren't particularly impressed by my prior statements
about the actor claim but, for lack of knowing what else to say, I'm going
to kind of repeat what I said about it over in the Phabricator tool and add
a little color.
The actor claim is intended as a way to express that delegation has
happened and identify the entities involved. Access control or other
decisions based on it are at the discretion of the consumer of the token
based on whatever policy might be in place.
There are JWT claims that have concise processing rules with respect to
whether or not the JWT can be accepted as valid. Some examples are "aud"
(Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC 7519.
E.g. if the token is expired or was intended for someone or something else,
reject it.
And there are JWT claims that appropriately don't specify such processing
rules and are solely statements of fact or circumstance. Also from RFC 7519,
the "sub" (Subject) and "iat" (Issued At) claims are good examples of such.
There might be application or policy specific rules applied to the content
of those kinds of claims (e.g. only subjects from a particular organization
are able to access tenant specific data or, less realistic but still
possible, disallow access for tokens issued outside of regular business
hours) but that's all outside the scope of a specification's definition of
the claim.
The actor claim falls into the latter category. It's a way for the issuer
of the token to tell the consumer of the token what is going on. But any
action to take (or not) based on that information is at the discretion of
the token consumer. I honestly don't know it could be anything more. And
don't think it should be.
There are two main expected uses of the actor claim (that I'm aware of
anyway) that describing here might help. Maybe. One is a human to human
delegation case like a customer service rep doing something on behalf of an
end user. The subject would be that user and the actor would be the customer
service rep. And there wouldn't be any chaining or nesting of the actor. The
other case is so called service chaining where a system might exchange a
token it receives for a new token that it can use to call a downstream
service. And that service in turn might do another exchange to get a new
token suitable to call yet another downstream service. And again and so on
and turtles all the way. I'm not necessarily endorsing that level of
granularity in chaining but it's bound to happen somewhere/sometime. The
nested actor claim is able to express that all that has happened with the
top level or outermost one being the system currently using the token and
prior systems being nested.. What actually gets done with that information
is up to the respective systems involved. There might be policy about what
system is allowed to call what other system that is enforced. Or maybe the
info is just written to an audit log somewhere. Or something else. I don't
know. But whatever it is application/deployment/policy dependent and not
specifiable by a spec.
On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <e...@rtfm.com> wrote:
Hi folks,
I've gone over draft-ietf-oauth-token-exchange-12 and things seem
generally OK. I do still have one remaining concern, which is about
the actor claim. Specifically, what is the RP supposed to do when they
encounter it? This seems kind of underspecified.
In particular:
1. What facts am I supposed to know here? Merely that everyone in
the chain signed off on the next person in the chain acting as them?
2. Am I just supposed to pretend that the person presenting the token
is the identity at the top of the chain? Say I have the
delegation A -> B -> C, and there is some resource which
B can access but A and C cannot, should I give access?
I think the first question definitely needs an answer. The second
question I guess we could make not answer, but it's pretty hard
to know how to make a system with this left open..
-Ekr
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited.. If you have
received this communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments from your
computer. Thank you.
_______________________________________________
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
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited.. If you have
received this communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments from your
computer. Thank you.
_______________________________________________
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
