UMA Dev telecon 2015-09-15

Owned by Eve Maler
Last updated: Sept 15, 2015
3 min read

UMA Dev telecon 2015-09-15

Date and Time

Agenda

  • Roll call
    Quick hits:
    • Re-re-discussing our meeting time slot (current one nets out to Singapore 4am)
    • GitHub repository update
    • Good place to keep the running list of our design questions, started last week? GitHub issues?
    • Approval of minutes of UMA Dev telecon 2015-09-08
  • Review initial draft generic API
  • AOB

Minutes

AI: Eve: Add design questions as GitHub issues.

We reviewed Allan's initial draft, which proposes a generic API for resource set registration. The first goal is to rough-out what this should look like, before determine the exact "contents". He's shooting for friendliness to non-object-oriented languages as well.

How would you indicate the AS to target? Should the server ID be on everything, or should it be a global resource class? Since it's not too hard to allow for the server ID to vary, maybe allow that. It's certainly possible in "wide-ecosystem" deployments to imagine one RS having to deal with multiple AS's. To save work on the part of the dev, we could save crucial state in the object. But note that certain artifacts are security-related, and we have to be careful how we save them. E.g., if we save the PAT in an object, it's a bearer token.

And where would the PAT go? Does the PAT become a parameter to a lot of things?

Since the PAT is simply an OAuth token, does it make sense to simply integrate an OAuth library for those pieces so that we're not reinventing anything? Roland's library does "all of the above", of course.

There are different ways to optimize depending on whether you have one RO registering a lot of resources or many ROs registering a few resources. A person structure that "contains" its resources would be one way to solve this. But then it starts to overlap what the dev has probably already done in their app. But if it's an "umaPerson", maybe it's okay. It's actually a "resource owner" specifically. (And may not be a person!)

While it's technically possible for a single RS to be able to protect different resources of an RO using different AS's, it's unlikely as a choice. Conclusion: Storing the AS as part of a resource data structure is probably an okay choice, since it correlates with the RO (in the RS context) pretty well.

To future-proof a bit, we could add an optional method that overrides the default AS."Make the simple things simple and the hard things possible."

Is it safe to use the resource set name in combination with the ID to disambiguate in the case of server-reused IDs?

Issue: Can an AS reassign the same rsid to a second resource set post-deletion of the first resource set? 'Cause that would be a problem.

More general/high-level design questions:

  • If we come to places where we have to choose between optimizing for one kind of deployment ecosystem vs. another, how do we choose?

It sounds like a "factory class" (approximately) wants to exist for a resource owner, and on creation of a registered resource set, it gets associated with its RO.

Issue: What's the best way to cross-reference between JSON structures? If you have 10 ROs, represented by an array of 10 objects, and you want to say that a resource set is owned by "RO 7", is that too fragile?

AI: Eve: Doodle poll for meeting schedules after Sep 22.

AI: Allan: Further editing, including today's input and the RPT endpoint.

Next week: Hopefully, if Roland's wifi is good, let's plan to walk through his code and get his design center lecture. (smile)

Attendees

As of 2015-07-31, quorum is 4 of 6. 

  1. Eve
  2. Roland
  3. Allan

Non-voting participants:

  • Jamie
  • Katie
  • Rebecka