Macaroons caveats are authentic anonymous claims, which seems a bit weird to me. Nevertheless, I consider Macaroons to be a great concept – when implemented correctly. POCOP token claims are not anonymous. Each POCOP token possessor must be registered (public clients can use dynamic registration to become confidential clients). Tokens are verified via introspection endpoints. AES-GCM chaining may be used instead of HMAC chaining to ensure integrity, authenticity and confidentiality. POCOP Tokens à la Macaroons vs. Macaroons à la POCOP Tokens: Non-anonymous Macaroons can be made using the POCOP recipe and fresh HMAC ingredients. The question is: Are they still Macaroons? -Igor P.S. Maybe https://en.wikipedia.org/wiki/Chain_of_custody is a more accurate term than Chain of possession. On Tue, Nov 23, 2021 at 12:40 PM Igor Zboran <izboran@gmail.com> wrote:
Hi Justin,
For the last few days, I've been trying to make POCOP compatible with Macaroons, but so far unsuccessful. The POCOP approach differs substantially from Macaroons.
Macaroons caveats are anonymous, anybody can append a new caveat, you should only trust restrictive claims in a caveat. POCOP claims are authenticated, you can trust any claims.
Macaroons are based on the HMAC(HMAC(HMAC(K1, m1), m2, m3)) construction.
POCOP is based on the HMAC(K3, HMAC(HMAC(K2, HMAC(HMAC(K1, m1), m2)), m3)) construction.
Regards
-Igor
On Mon, Nov 22, 2021 at 6:16 PM Justin Richer <jricher@mit.edu> wrote:
Igor,
I was unable to make the meeting, but how does your POCOP approach differ from Macaroons and the caveat system there?
— Justin
On Nov 19, 2021, at 11:15 AM, Igor Zboran <izboran@gmail.com> wrote:
Hi all,
I'd like to give more context/information.
"POCOP Tokens" is my personal research activity aimed at exploring the possibility of using nested, chained HMAC constructions in authorization processes. Some nested, chained HMACs have an interesting feature, they don't need to share keys between "nests" to generate the verifiable MAC. Such constructions address, for example, a scenario when one resource server needs to access another resource server in order to fulfill the client request that uses a self-issued token.
Your comments are valuable, thanks for the feedback, I really appreciate it.
-Igor
On Thu, Nov 18, 2021 at 8:12 PM Alec Laws <malcolm.laws@gmail.com> wrote:
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-11-18
UMA telecon 2021-11-18Date and Time
- *Primary-week Thursdays 06:30am PT; Secondary-week Thursdays 10:00am PT* - Screenshare and dial-in: https://zoom.us/j/99487814311?pwd=dTAvZi9uN0ZmeXJReWRrc1Zycm5KZz09 - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar
Agenda
- Approve minutes of UMA telecon 2021-09-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-09> , UMA telecon 2021-09-16 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16> , UMA telecon 2021-09-23 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-23> , UMA telecon 2021-09-30 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-30> , UMA telecon 2021-10-14 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-10-14> , UMA telecon 2021-10-21 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-10-21> , UMA telecon 2021-10-28 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-10-28> , UMA telecon 2021-11-04 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-11-04> , UMA telecon 2021-11-11 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-11-11> - Delegation Use Cases - Proof of Chain of Possession (POCOP) Tokens - AOB
MinutesRoll call
- Quorum: No
Approve minutes
- Approve minutes of UMA telecon 2021-09-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-09> , UMA telecon 2021-09-16 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16> , UMA telecon 2021-09-23 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-23> , UMA telecon 2021-09-30 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-30> , UMA telecon 2021-10-14 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-10-14> , UMA telecon 2021-10-21 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-10-21> , UMA telecon 2021-10-28 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-10-28> , UMA telecon 2021-11-04 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-11-04>
Deferred
*The Kantara All members meeting is Dec 8th, 11-1230ET (it's virtual, link TBD)*
Delegation Use Cases
Reviewed more pp2pi <https://www.drummondgroup.com/pp2pi/> use-cases, broken down by objective and mapped to whther uma or uma delegation can meet the goal
Will continue this discussion next week
- payer insurance codes are often opaque to the patient/covered person
Proof of Chain of Possession (POCOP) Tokens
https://github.com/uma-email/poc
A client can use any IDToken with any UMA ticket. The Correlated Authorization mechanism ensures that there is some open UMA transactional context included in any pushed ID claims
What is the threat that Proof of Possession <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-04> (or mTLS) doens't address that requires the "chronological tamper-resistant record"?
Report on FHIR Vulns
reviewed some initial diagrams for this: https://docs.google.com/presentation/d/1aDTD6nv5vza8gDsSRGV6X5tzRoQdIv5V9aU8...
- FHIR itself is simply the data model - FHIR had the author refine their statement that it was 'FHIR Implmentations' that had the vulnerabilities - SMART on FHIR is the HL7 'approved' authorization strategy - UDAP → artifacts that needs to exist from a trust framework to support DCR/wide-access - HEART → profiles of OAuth/UMA for SMARTonFHIR scopes
AOB
- We are planning a 3 hour working session on December 9th, we will use extend the normal call from 930-1230ET - Want to make progress on some of the in-progress docs, have them in a consistent state - Eve, Nancy, Alec, Andi - If you're up to attend, please email Alec, or leave a comment on these minutes
Topic Candidates (from previous telcons)
- Delegation and Guardianship - Outcome of user stories discussion - PDP architecture includes the concept of governance registry/discovery - TOIP/SSI are starting to define this ecosystem function - ANCR records update - Privacy as Expected/ANCR update : 2/3 weeks out (Sal?)
Attendees
As of October 26, 2020, quorum <http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)
Voting:
1. Steve 2. Alec
Non-voting participants:
1. Scott G 2. Scott F
Regrets:
1. Sal 2. Nancy 3. Eve
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma