The following have been raised implicitly or explicitly in the various discussions this year (note some of these items overlap):
- What scenarios do we think should apply?
- User goes to tool via LMS
- User goes to tool via portal (i.e., not in a class context)
- User goes directly to tool (unmediated)
- other?
- n-tier delegation: who is trusting whom? Who are or should be the actors?
- to assert authenticated user
- to assert attributes
- SSO and session (may or may not relate to the use of iframe). What is the bearing on user experience?
- How do our questions about the LTI TP relate to the generic problem of launching a widget?
- What are the principles/constraints that inform our proposed solutions?
- E.g., Do not require the back-end service to trust the LMS/1st tier's assertions about a user session
----------
Here are some thoughts I came away with after our Friday IAM for LTI call. Please correct/supplement/contradict as appropriate. --Keith
----------
Terms from SAML: Identity Provider (IdP); Relying Party or Service Provider (RP/SP)
Terms from LTI: Tool Consumer (TC); Tool Provider (TP)
There are two basic models:
1) LMS/TC as Identity Provider(IdP): Fits well when tool provider (TP) services are widget-like things running in some sense in the context of the LMS/TC
2) LMS/TC as just another Relying Party (RP) from security perspective: Fits better when the tool provider (TP) services are more free standing or when one can imagine a learner/instructor going directly to the TP service NOT mediated by an LMS/TC
In model 1), the LMS by definition incorporates an SSO solution and the advice is rely on an existing SSO protocol, whether SAML, OpenIDConnect or whatever. In any case, don't create yet another SSO solution--security is a hard problem.
In model 2), a newer component--Attribute Providers or Attribute Authorities might help solve some of the challenges of TPs getting access to needed user information.