https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-01-10
MinutesRoll call
Quorum was not reached.
Meeting logistics
- No call on Jan 24 or Jan 31
...unless we've got lots of things under discussion and we've got a chair
pro tem available.
Approve minutes
- Approve minutes of UMA telecons 2018-12-06
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-12-06>
, 2018-12-13
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-12-13>
, 2018-12-20
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-12-20>
Deferred.
Last call: Identiverse call for presentations is open till Jan 11
Eve has one UMA-related submission in the works.
High assurance of the RO to the RqP
- Is Peter available to describe his method of strong binding from Alice
registration time to ensure "high RO IAL" in more detail?
Peter isn't available today.
Alec thought about the general CIBA-ish topic and wondered if the AS could
use request_submitted error path somehow to leverage CIBA to authenticate
the RO and assure the RqP of the RO's identity as required. George notes
that there has been discussion in CIBA about a "questioning API", a la the
old Liberty interaction Service
<http://projectliberty.org/liberty/content/download/885/6231/file/liberty-id…>.
Eve asks: Isn't identity assurance of some sort the entire point of OIDC on
top of the authorization endpoint? George: Except that this is why CIBA is
about a "back-channel" flow. Hmm, note that what they are calling
"back-channel" is more like "out-of-band", without the use of redirection.
They don't mean asynchronous. There is a "front-channel" interaction with a
device that the user in question was never redirected to. It's an attempt
to synchronize using an asynchronous method. The benefit of UMA is supposed
to be that it's prepared to go totally asynchronous. The request_submitted
error enables some kind of synchronous check with the RO (which perhaps we
could leverage for a forceAuthn check of Alice if we can figure this out).
Can CIBA be turned into a clean Interaction Service that we could then use
for the specific places where it would be valuable, such as the AS checking
the RO and the AS checking the RqP? What questions can be asked of the user
(RO in our use case)? We discussed the concept of a "binding message" (see
binding_message defined here
<https://openid.net/specs/openid-client-initiated-backchannel-authentication…>),
but its use seems to be limited more to a type of one-time code that
defeats an MITM attack or similar that disrupts messaging between the
consumption and authentication device.
Are there privacy considerations in the RqP learning the RO's identity
information or authentication level at any point before the RqP has been
granted access to the resource? If the RqP has a condition such as "the RO
must have authenticated to level X in the last N minutes", then presumably
those conditions along with the RO's policy conditions must all obtain
before access should be given. Might this affect the UMA set math as well?
Potentially, yes.
*AI:* Eve: Ask Bjorn about availability of GSMA Mobile Connect use cases
that get into more detail than the CIBA section
<https://openid.net/specs/openid-client-initiated-backchannel-authentication…>.
Is this link <https://mobileconnect.io/use-case/> in the right direction?
George thinks there's a document that is 30-40 pages in length.
Nancy notes that the Apple Health app seems to ask for access to medical
records once, but then gets updates continually thereafter. It's likely
OAuth-based, where she can withdraw consent for that app connection,
pairwise. The model still seems to be "Alice-to-Alice sharing". If Alice
were to want to share a record with Dr. Jones, we now get into use cases
like: Alice wants Dr. Jones to prove he's himself once a month (classic
UMA); Dr. Jones wants Alice to prove that the records from a specialist
that she's sharing with him are truly hers to share (the new CIBA-ish use
cases we're contemplating)...
UMA business model
- Draft report work
Eve got some work done on her draft, with help from Domenico on new
diagrams. She and Tim will try and get together before our next call and
press ahead.
IETF 104 plans
- Resource-indicators
<https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/>
draft
relevance either way?
- Next steps?
The resource-indicators draft seems to mean both "resource server" and
"protected resource". UMA allows for registration of resources, which
spells out the specifics. George suggests that this spec is trying to split
the difference in management overhead level for high-value resources and
low-value resources in splitting the difference in the meaning. We had
previously discussed (but, at the time, discarded) the idea of having
"wildcards" (need to find the specific GitHub issue) when registering
resources, so that you don't have to fully qualify resource names when
registering them. Lots of types of services might have millions of
resources – or put another way, an infinite number of dynamic resources,
depending on how they're created, torn down, etc. Having to register them
in a fully qualified way may be too static, too heavyweight, etc.
The spec binds access tokens to a particular URI. Because most aren't
downscoping their tokens, leakage of tokens will enable too-great service
access for its lifetime. This binding is like an audience check, only for
the original service it was meant for. UMA's equivalent, in part, is the
nature of the RPT and set math, and the fact that it represents
<https://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gu…>
an
intersection of who wants it and who's granting it. The nature of policy
conditions makes the RPT a bit more "sender-constrained" (that is,
constrained by what the RO wants to happen) by definition, if not in
construction. However, the new reverse-proxy phishing attacks are basically
stealing session cookies, which the RPT is a bit like. We should take a
look at any new mitigations we should be applying along the lines of true
"sender-constraining".
Discussion for next time:
- Sender-constrained RPTs?
- Comments on OAuth-distributed draft?
- Contributing the UMA2 specs?
- Attending IETF 104?
Attendees
As of 18 Oct 2018, quorum
<https://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 8. (Domenico, Peter, Sal, Andi, Maciej, Eve, Mike, Cigdem)
1. Domenico
2. Sal
3. Eve
Non-voting participants:
- Alec
- George
- Nancy
- Tim
Regrets:
- Peter
- Cigdem
- Mike
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-12-20
(Many thanks to Domenico for his many years of awesome graphics!)
MinutesRoll call
Quorum was not reached.
Meeting logistics
- Doodle poll is now closed: winning meeting time is *Thursdays 6am
PT/8am CT/9am ET/2pm UK/3pm CET*
- We will start up again on *Thursday Jan 10 at the new time*
If you subscribe to the Kantara calendar, updates there (which Eve will do
shortly) should simply show up. If you are a non-voting participant and
wish to receive an invitation (through your email address so that it goes
on to your preferred calendar) in addition to your subscription to the
Kantara calendar, let Eve know.
Approve minutes
- Approve minutes of UMA telecon 2018-12-06
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-12-06>,
UMA telecon 2018-12-13
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-12-13>
Deferred.
Reminder: Identiverse call for presentations
<https://www.cvent.com/c/abstracts/0e1feab0-e824-428e-abea-9f5d54e03059> is
open till Jan 11
Your holiday break is the *perfect* time to write those proposals! Don't
think in terms of "the single UMA talk" or whatever. Implementation details
are awesome. "Forward-thinking" / "theoretical" can be considered as well.
Particularly if you're new to all this, you can reach out to Andi (see the
email address on the site). Treat January 11 as a hard deadline this time!
High assurance of the RO to the RqP
- CIBA Core
<https://openid.net/specs/openid-client-initiated-backchannel-authentication…>
spec
is just out
- Previous discussion: May 31
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-05-31>
, Jun 7
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-06-07>
, Sep 13
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-13>
, Oct 18
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-18>
, Dec 6
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-12-06>
, Dec 13
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-12-13>–
Peter described a method of strong binding from Alice registration time to
ensure "high RO IAL"
Deferred until we can put Peter on the spot. [image: (smile)]
UMA business model
- Look at publishing new/revised draft reports
Eve has been working to capture our "UMA Legal Role Definitions" work in a
new document
<https://docs.google.com/document/d/1Accua4AWQrl6N0trjdj4NFA0fyDpOn2B1orupCu…>
(request
access if you can't get in to the GDoc). Andi spoke in favor of publishing
it as a draft report and is willing to help with developing a new
deliverable that focuses on the "IRM" aspects (use cases at the transitions
of the numbered cradle-to-grave scenarios in the slide deck). This is not
fully "standards-based" yet but could go in that direction. Tim asks: Are
the reports key to encouraging adoption of UMA at this point? Certain use
cases, at least, seem common – particularly going from state 1, managing a
minor's resources, to state 2, enabling the now-adult person to take over
management of their own resources. This seems particularly frequent in
healthcare.
*AI:* Andi and Eve: Met early in the new year to work on that second
deliverable on "UMA relationship use cases".
*AI:* Tim and Domenico: Review the GDoc over the holidays.
What are the sectors where UMA is being seen? Eve: financial and
healthcare; for financial, the specific use cases differ
(enterprise/employee delegation, API protection, pensions dashboard, etc.).
Various IoT use cases as well across sectors. Alec: healthcare, giving
access to someone in their circle of care. The biggest challenge is
compliance of all the parties. The RO is not able to choose their own
AS/ASO, and ensuring privacy is important. Government-to-citizen as well,
where SSI tends to come in, and also giving businesses access from an
authoritative source. Colin: IDoT discussion in Kantara was ahead of its
time.
UMA and VCs discussion
This thread
<https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/MVh9KUJuD…>
in
October sort of petered out because it was on two lists, but it's an
interesting one. Let's think about it in the new year.
IETF 104
Let's also think about plans for this in the new year.
Schemas and overlays
Colin: The core of this work is starting up, so please be aware of it.
Attendees
As of 18 Oct 2018, quorum
<https://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 8. (Domenico, Peter, Sal, Andi, Maciej, Eve, Mike, Cigdem)
1. Domenico
2. Andi
3. Eve
Non-voting participants:
- Alec
- Scott
- Tim
- Colin
Regrets:
- Nancy
- Sal
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-12-13
MinutesRoll call
Quorum was not reached.
Meeting logistics
- Reminder: Doodle poll is still open
<https://doodle.com/poll/78ymsmn38hss72qs> for new meeting time in the
new year; respond by Tuesday of next week
- Meeting at the *usual time* (Thursday 9am Pacific) on Dec 20; *not
meeting* on Dec 27
Approve minutes
- Approve minutes of UMA telecon 2018-12-06
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-12-06>
Deferred.
Reminder: Identiverse call for presentations
<https://www.cvent.com/c/abstracts/0e1feab0-e824-428e-abea-9f5d54e03059> is
open
Deadline is 11 Jan 2019.
180 degrees / decoupled / CIBA use cases
- Use case doc
<https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/Vk3YpypIL…>
from
Nancy
- Latest CIBA specs: MODRNA status page
<https://openid.net/wg/mobile/status/>, FAPI profile
<https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md?filev…>
- What are *practical* methods, leveraging the existing UMA flows, for a
requesting party to know the RO is the RO?
- How does the RS know the RO is the RO?
- Previous discussion: May 31
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-05-31>
, Jun 7
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-06-07>
, Sep 13
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-13>
, Oct 18
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-18>
, Dec 6
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-12-06>
–
please refresh your memory
The MODRNA status page is here <https://openid.net/wg/mobile/status/>. The
last issues have just been closed. The plan is to have a CIBA Core spec
(current draft here
<https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=asc…>
–
thanks, Bjorn!), which will move to the Connect working group after IPR
issues are resolved, and a MODRNA profile, which will stay in the MODRNA
group, along with the FAPI profile. The specs were split just yesterday,
and tomorrow the specs will be sent out for public review before the
Implementer's Draft vote. Beyond the notification modes we discussed, the
substantive changes are around greater implementability and focusing
strongly on the mobile use case, and how to treat the return values, and
adding security and privacy considerations. Brian C and Dave T did a lot of
work on it.
We discussed Mike's analysis from Jun 7
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-06-07>.
Bjorn wonders if his concerns from that time aren't as applicable to the
Core spec as to the MODRNA profile.
It would be a good idea for us to review the Core spec at this juncture. We
can analyze if, in fact, the "UMA business model" approach is accounted
for, with multiple parties and delegation between them. The Oct 18
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-18>
notes
go into detail on why this is important.
The PAT is the only in-band UMA artifact that suggests a communications
channel we could use to prove how Alice could prove who she is to the RqP's
satisfaction. Peter suggests that they are doing something like this: They
are leveraging a "modified use of scopes" to determine access to things.
Alice's IdP has a tightly coupled relationship with the AS (effectively
colocated) but they have a protocol-level separation. The scope is placed
into the access token that is presented to the RS, but the scope is signed
by the AS, which proves that it was Alice that authorized the access to the
resource. This sounds like the ecosystem circumstance described in the last
paragraph of UMA Grant Sec 5.7
<https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#trus…>.
Adrian notes that a Verifiable Credentials approach would give a level of
flexibility of how you would achieve that trust. (They're actually using a
very long list of resource-type-bound scopes to achieve this now.) Family
members and non-family members need to be treated differently. In Peter's
case, they have done in-person proofing.
How can we prove that the "Alice" of the managing-resources (at the RS) and
the "Alice" of the controlling-access (at the AS) is the same at all times?
Is there a good IAL (identity assurance level) across all interactions? In
Peter's implementation of sharing, they have keys that are under management
and there is a strong binding when Alice first starts registering proofing
documents (passports, etc.) and strong lifecycle management throughout,
along with consent receipts as part of the RPT(-equivalent). Very
interesting.
It seems that we are on the right track for potential profiling (or
something), by asking the right questions in specific enough form. More
next week.
Attendees
As of 18 Oct 2018, quorum
<https://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 8. (Domenico, Peter, Sal, Andi, Maciej, Eve, Mike, Cigdem)
1. Domenico
2. Peter
3. Sal
4. Eve
Non-voting participants:
- Scott
- Thomas
- Nancy
- Adrian
- Bjorn
- Colin
Regrets:
- Andi
- Cigdem
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
UMA-tarians,
I was wrong on the last call... we only have swaggerized the oxd API's:
Swagger UI for oxd is here (including UMA RS endpoints):
https://gluu.org/swagger-ui/?url=https://raw.githubusercontent.com/GluuFede…
We generate Markdown from annatations in the code, which get published
in our mkdocs pages.
But we might do swaggerize the UMA API's in the future--it's not that
much harder to generate the swagger yaml file then the markdown.
- Mike
On 2018-12-07 20:35, Mike Schwartz wrote:
> Yuriy,
>
> On the last UMA call, I volunteered to send a copy of our UMA Swagger
> doc to the list. How can I get it/them?
>
> - Mike
>
> -----------
> Michael Schwartz
> Gluu
> Founder / CEO
> mike(a)gluu.org
> https://www.linkedin.com/in/nynymike/
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-12-06
MinutesRoll call
Quorum was reached.
FYI, the Implementations page
<https://kantarainitiative.org/confluence/display/uma/UMA+Implementations> has
been updated
In about two months (that's the HIMSS timeframe -- Feb 11-15 in Orlando),
there may be an update to the HIE of One listing reflecting the product
side (Trustee). Adrian could be interested to attend HIMSS if there is
someone willing to pay his way. And perhaps we should look at interop
testing at HIMSS.
Mike will update the Gluu listing to reflect the upcoming December ship
date of the Gluu Gateway and the "Swaggerization" of the RS and (updated)
client code. Swagger (technically OpenAPI <https://www.openapis.org/> is
what they're using) is a kind of machine-readable API documentation that
allows automated stubbing-out of applications. It's not the only API
description language but it's pretty much the most popular. Since oxd is
basically middleware (using Lua <https://www.lua.org/>), its Swagger isn't
that interesting for a larger Swaggerization project. They changed it a
lot, taking out "mix mode".
What would it take to add an UMA module into Swagger? Then infrastructure
would already be available to the online testing tools. If you could
document which UMA scopes are required, security provisioning could be
automated. Mike will share what they've already done. It may or may not be
that helpful given the need to customize.
Meeting logistics
- Doodle poll is open <https://doodle.com/poll/78ymsmn38hss72qs> for new
meeting time in the new year – this is a *sample week*, and likely the
first week we would start the new time if we pick one
- Meeting at the *usual time* (Thursdays 9am Pacific) on Dec 13 and 20; *not
meeting* on Dec 27
Approve minutes
- Approve minutes of UMA telecon 2018-11-15
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-11-15>
APPROVED.
Identiverse call for presentations is open
Here
<https://www.cvent.com/c/abstracts/0e1feab0-e824-428e-abea-9f5d54e03059>.
Deadline is 11 Jan 2019.
180 degrees / decoupled / CIBA use cases
- Secure, trusted sharing in both directions
- Use case doc
<https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/Vk3YpypIL…>
from
Nancy
- Latest CIBA specs: MODRNA status page
<https://openid.net/wg/mobile/status/>, FAPI profile
<https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md?filev…>
We analyzed the use case doc. The "group X" parties seem to be a species of
requesting part that have a motivation to share an UMA resource owner's
data that they are a custodian of (they are in an UMA resource server role,
we think), but they carry some liability for inappropriate sharing so they
are going to want to be extra-careful about "group Y" (Alice) being who
they say they are (the UMA resource owner) and also about others (Joe and
Erica, the UMA requesting parties) being who they say they are – meeting
Alice's policy.
In previous discussions, we noted that the requesting party wants to ensure
that it's truly Alice who is the resource owner. Is there also a need for
the resource owner to know that Alice is the RO?
Is authentication (of Alice/the RO particularly) something that we can
connect to auditability, as it relates to our UMA business model work?
Right now the PAT is the main thing that is "in band". Sal notes that this
could connect to consent receipts as well.
Eve has a plan to draft UMA business use cases and business/technical
mappings (technical artifacts and legal devices) for people's perusal over
the next couple of weeks. Andi says he'd also like to see us put some more
thought into how we could handle cases where multiple resource owners exist
for the same resource. Eve adds: These might include joint checking
accounts, or two parents controlling a child's health record, etc.
UN Commission on Refugees
Tim asks if anyone has looked at their call for a proposal
<https://www.ungm.org/Public/Notice/80196> for blockchain-related
identities being issued; he's been talking to Colin about it and wonders
about UMA's relevance. Cigdem just started looking at it. Adrian notes that
HIE of One combines UMA and self-sovereign technologies and has been
working on similar use cases. Alec notes that Identos's solution similarly
has UMA on one side and a self-sovereign type of technology on the other
side. Nancy mentions some interest as well.
Colin remarks that responding to such calls tend to require a fair amount
of resources and a big team. Kantara could potentially put a proposal
together but a fairly large organization may need to prime the effort.
Adrian mentions ID4D <http://id4d.worldbank.org/>.
Attendees
As of 18 Oct 2018, quorum is 5 of 8. (Domenico, Peter, Sal, Andi, Maciej,
Eve, Mike, Cigdem)
1. Peter
2. Sal
3. Andi
4. Maciej
5. Eve
6. Mike
7. Cigdem
Non-voting participants:
- Alec
- Adrian
- Bjorn
- George
- Nancy
- Colin
- Tim
Regrets:
- Domenico
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
