Grant rev 06
<https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html>
and FedAuthz
rev 06
<https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-06.…>
are now up! These contain implementations of all the agreed-to and purely
editorial solutions to Public Comment (and a couple of minor post-Public
Comment) issues to date.
Issues #335, #337, and #339 (and various sub-issues) are worth discussing,
and I'd like to do that in tomorrow's call. I've put some thoughts into the
threads already to kick things off. Please feel free to respond in this
thread prior to the call!
In approximate order of importance:
1. 337a <https://github.com/KantaraInitiative/wg-uma/issues/337>: iat
and nbf in the token introspection response don't say what should happen
if the permission-level value is missing, while exp does
<https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-06.…>.
We started discussing this last week
<http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-20>
and didn't quite come to a conclusion (it was shaping up to be "remove what
we say even in exp"). Can we decide this quickly?
2. 337c <https://github.com/KantaraInitiative/wg-uma/issues/337>/d: It's
been proposed that we register a client metadata element in the "OAuth
Dynamic Client Registration Metadata Registry" so that
claims_redirect_uri can be formally dynamically registered, and also to
make it REQUIRED for public clients to register these URIs. Thoughts?
3. 337f <https://github.com/KantaraInitiative/wg-uma/issues/337>: This
was a request for more set math clarification, specifically around what
happens if there are multiple permissions in the permission request. To me
it was obvious that "it all works the same", but skepticism was expressed.
:-) Please see my example in the GitHub thread. Can we riff off that as a
solution?
4. 337b <https://github.com/KantaraInitiative/wg-uma/issues/337>: Is my
suggestion a good one to add a statement that the client MAY be
confidential or public, for clarification?
5. 339 <https://github.com/KantaraInitiative/wg-uma/issues/339>: It
seems our description of object vs array in permission requests came out
somewhat ambiguous. We have an opportunity here. Should it be possible for
RS's to choose which way they request a single permission, with the AS
picking up the slack?
6. 335c/d <https://github.com/KantaraInitiative/wg-uma/issues/335>: It
was suggested to break out Grant Fig 1
<https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html#high-…>
into an RO vs RqP flow to show asynchronicity, and then also the latter to
be broken out into claims push and interactive claims gathering flows.
Theoretically I liked the ideas, but trying to implement them and getting
some feedback, I didn't anymore. I think devs will prefer a single summary
diagram with all the entities. Thoughts?
7. 337g <https://github.com/KantaraInitiative/wg-uma/issues/337>: I'm
recommending no change regarding further protecting permission tickets as
being single-use. Sound good?
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Hi all,
Eve sent me an email off-list last night asking "Are we going to be sorry
we don't have a named object for a single permission?" With clarification
this morning, it turns out she was talking about the token introspection
endpoint :)
You'll remember the response currently looks like:
{
"active":true,
"exp":1256953732,
"iat":1256912345,
"permissions":[
{
"resource_id":"112210f47de98100",
"resource_scopes":[
"view",
"http://photoz.example.com/dev/actions/print"
],
"exp":1256953732
}
]
}
With a bit more discussion, the only thing I could see as potentially
useful was to have permissions as an object (instead of array), and use the
resource_id as the key in the object. To do this, we'd have to then make
its value an array so that if you have multiple different scopes with
different expiry times, they could be expressed effectively, so:
{
"active":true,
"exp":1256953732,
"iat":1256912345,
"permissions":{
"112210f47de98100":[
{
"resource_scopes":[
"view",
"http://photoz.example.com/dev/actions/print"
],
"exp":1256953732
},
{
"resource_scopes":[
"edit"
],
"exp":1256953750
}
]
}
}
I'm by no means convinced that this is very much more useful than the
current version, and is thoroughly backwards-incompatible, but the object
structure could be useful if RPT permission arrays were to get very big.
Thoughts?
Cheers
James
http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note…
2017-07-21
Attending: Eve, Kathleen, Tim
We started looking at chart 6 (not sent in email). Tim would like to ensure
that we get the pairwise (or more) relationships, legal devices, and
artifacts locked down so that he can revise the definitions. The column
mentioning "pairwise" should probably take that word out because some of
the artifacts definitely represent more than two of the roles.
A *license*, versus a *contract* specifically, gives flexibility around
number of parties and promises. It's about tracking permissions. Some
permissions are given with some conditions. The license gets revoked if the
conditions aren't kept. A license scales better than a contract as a legal
mechanism. (Kathleen refers to the licensing model as essentially an
authorization model.)
A DURSA (data use reciprocal service agreement), from healthcare, is an
example of a surrounding contract that could be used to encompass the kind
of license we're talking about. Many of the use cases we've collected – a
nanny collecting kids from daycare, giving someone access to a connected
car – show that there's a desire to ensure a contractual apportionment of
liability across to a requesting party in addition to licensing.
If this were a contract, the RO Alice would be the offeror, the resource
access permissions would be the consideration, and the RqP Bob would
theoretically be the offeree – but where is the acceptance part? In the
technical layer of UMA, Bob might not have acted positively at all to get
access. His client software might have "pushed" claims about him without
any action on his part, Alice's AS might issue a PCT to his client that
represents claims previously collected and the client subsequently "pushes"
that PCT back, but that happens silently. Does that constitute acceptance?
Do we have to build that into our model clauses? Using a licensing model,
RqP Bob *doesn't* have to accept, and any overarching contract layers could
build that in only if they want to. Developing contractual-level tools is
out of scope for us.
The term "access contract" came from UCITA law. Do we want to use it? It
appears in the role definitions, but should we step back from it? Actually,
this is between the RO and ASO. So it appears on the wrong line; it should
be on the RS-ASO line, not RO-RSO. Or was it correct after all? Are the RSO
and ASO both parties to the access contract? The RO becomes *the* licensor,
and do the ASO and RSO both become the sub-licensors? It would be helpful,
in the "Legal Relationship" column, to always state "*so-and-so* is the
*role* for *whom-downstream* of *what* on behalf of *whom-upstream*". E.g.,
"RSO is sub-licensor on behalf of RO". Maybe we can even construct the
columns so that each variable gets filled in, in order, to form a
"sentence"?
The RO is at the "head" of the relationships. The RO owns the access
rights. (In US healthcare, under federal law, a patient owns right of
access.)
The ASO-CO artifact of OAuth client credentials is only related to that
pairwise relationship (not to RqP BoB or to the PCT; this should be
relegated to a separate row). It could be related to a contract, say, ToS.
It's a *potential place* where conditions that are protective of Alice
*could* go, e.g. to ensure that the client (later interacting with Bob,
e.g. sharing Alice's data, storing Alice's data, etc.) acts in a way that
is aligned with Alice's interests.
At the end of the day, the legal aspects have to match the UMA flows and
artifacts exactly.
*AI:* Eve: Try to do an edited matrix in GSlides form for the group.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
8am PT/11am ET
http://join.me/findthomas
We'll have fresh role definitions, mappings, and diagrams. Good times!
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-20
MinutesRoll call
Quorum was reached.
Approve minutes
Approve minutes of UMA telecon 2017-06-29
<http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-06-29>
and
UMA telecon 2017-07-13
<http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-13>:
APPROVED by unanimous consent.
UMA 2.0 work
Is the right distinction in the Disposition of Comments document
<http://kantarainitiative.org/confluence/display/uma/UMA+V2.0+Disposition+of…>
"Would
the change potentially cause anyone to raise a new IPR issue or not?",
rather than "Is it 'editorial' or 'technical'?" So if something goes from,
say, MUST to something weaker (SHOULD or MAY), that would (could?) raise
IPR issues. But just clarifying something that was unclear in the Draft
Recommendation would presumably be editorial. Andrew asks: If no one makes
a necessary claim, does it matter? "The tree has already fallen in the
forest." [image: (smile)] The WG will make its case in the comment log
where anything seems marginal.
Finalizing the specs
Sample motion when the time comes: "Approve UMA 2.0 Grant and FedAuthz revs
06 as amended by the instructions of UMA telecon 2017-xx-xx as Draft
Recommendations and forward them to the Kantara Leadership Council to
request certification for an All-Member Ballot as Recommendations."
#332 <https://github.com/KantaraInitiative/wg-uma/issues/332>: If the AS is
"basically" expiring a previous PCT when it goes to a new authorization
process, should we say it MUST? It's more like any previous PCT from a
previous assessment has be superseded/overcome by events (namely, "one
process/one ticket lifecycle"). How explicit do we need to be about this,
for implementers to understand this clearly? We're inclined not to add more
refresh token-like text, despite the suggestion, because it's a little too
prescriptive, and we agree with the commenter's interpretation that *"I
would say, that according to the current version, the AS can really choose,
whether to expire PCT when issuing a fresh one and the client is not forced
to discard the old one."* Using this behavior, the AS and client would each
simply have old PCTs from previous authorization processes and could
issue/use them for any future authorization processes they want. The
wording throughout Grant doesn't prevent this; we checked. Do we now need
to consider *clarifying* that this "multiplicity" of uses is okay? Is it
ambiguous the way things stand? That is, Eve's reading, in the issue, of
"basically" expiring is not required. Justin, James, and Mike (Yuriy) all
interpret the current text to be okay with more than one-time use.
Optimization of future experience is basically the rationale for PCTs, so
this makes sense.
Andi brings up the security and privacy considerations; we do cover these,
and revocation is also covered, so we're good there. And the AS can always
expire at will.
No change in the wording.
#337 <https://github.com/KantaraInitiative/wg-uma/issues/337>:
- exp/iat/nbf: There was an original reason for the "split" logic of
talking about what happens when exp is absent vs the others. "If the
parameter is absent, the permission does not expire." We tried to mean that
the permission could live on past the token lifetime, but this is
nonsense. [image:
(smile)] What if we delete this sentence, keep the three other sentences
allowing the token-level value(s) to take precedence (or refactor that
sentence out to the token level), and live with the fact that we don't say
anything about the absence of the OPTIONAL values? What is our intent about
implementers' behavior? The RS's behavior is about cache control. The AS is
likely not to hand back something already expired. Everything beyond
active=true is a hint. So the RS could just try again if it didn't get what
it wanted.
- Did a quick tour through the other items. Most should be easy for
disposition.
UMA logo ideas
AI: Eve: Email out Domenico's first logo idea. Let's send thoughts his way.
Attendees
As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve,
Mike, Cigdem)
1. Domenico
2. Sal
3. Andi
4. Maciej
5. Eve
6. Mike
Non-voting participants:
- James
- Justin
- Andrew
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-13
MinutesRoll call
Quorum was not reached.
Approve minutes
Approve minutes of UMA telecon 2017-06-29
<http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-06-29>:
Deferred.
UMA 2.0 work
*#328 <https://github.com/KantaraInitiative/wg-uma/issues/328>:* how
client-contributed scopes are mapped to resources during authorization
assessment: Eve's first iteration was "Treat each scope in (
*ClientRequested* ∩ *ClientRegistered*) as applying to all
matching resource-bound scopes in *PermissionTicket*." She's thinking that
it would be more accurate to say something like "...all scopes associated
with resources appearing in *PermissionTicket*", and then we could add ",
with the scope matching performed as described in Section 6.2.1 of
[RFC3986] (Simple String Comparison)."
Let's give this wording a try in context (published draft) and see if it
makes sense there.
#334 <https://github.com/KantaraInitiative/wg-uma/issues/334>: the IANA
registration request for the JWT permissions claim and its constituent
parts: Justin suggests that we need to have a paragraph talking about the
security and privacy considerations of putting this information into the
token vs. an introspection response, because the token is exposed to the
client. The permissions claim and its sub-claims give tools directly usable
by those who want to use the "local validation of self-contained tokens"
path.
Furthermore, the sentence in the Introduction is too modest: "Further*,
with the use of token introspection,* authorization grants can increase and
decrease at the level of individual resources and scopes." We can get rid
of the italicized stuff.
We have the following options:
1. Remove our registration request.
2. Specify how to "validate a self-contained token locally" in a
separate document, with security and privacy considerations.
Do we have enough real-world implementation experience to know what the
considerations are? What is the sensitive information in the token? In a
typical OAuth access token, there are typically scopes. In our permissions
structure, there are resource IDs, scopes, expirations, etc. Also, there
may be permissions that cross RS's. Is this sensitive wrt an individual RS
too? Maybe it's trivial for an RPT that doesn't cross RS's, but not
otherwise. Maybe it requires encryption per array object or something. Any
considerations section would have to explicitly push responsibility onto
the implementer.
Eve speaks in favor of option 2. Kathleen notes that it's good to keep
solving this properly on the roadmap. Sal agrees. James agrees. We have
consensus.
Editorial actions: Remove the IANA request for JWT claims, and edit the
Intro sentence.
Finalizing the specs
Sample motion when the time comes: "Approve UMA 2.0 Grant and FedAuthz revs
06 as amended by the instructions of UMA telecon 2017-xx-xx as Draft
Recommendations and forward them to the Kantara Leadership Council to
request certification for an All-Member Ballot as Recommendations."
UMA logo ideas
tbs
Attendees
As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve,
Mike, Cigdem)
1. Sal
2. Maciej
3. Eve
Non-voting participants:
- Justin
- Kathleen
- Bjorn
- Scott F
- John W
- Jin
- James
- Robert
Regrets:
- Domenico
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
