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-18

Date and Time

Agenda

Minutes

Roll call

  • Quorum: No

Approve minutes

Deferred


The Kantara All members meeting is Dec 8th, 11-1230ET (it's virtual, link TBD)


Delegation Use Cases

Reviewed more 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 (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/1aDTD6nv5vza8gDsSRGV6X5tzRoQdIv5V9aU8o3Z632A/edit#slide=id.p

  • 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 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