federatedSession description vague and too specific to LTI

[mashbourne]

Background How are events identified as being part of the same user session? Seeking background to the LtiSession entity LtiSession suggestions

I think federatedSession naming implies it should be the "super session" that should hopefully track user across many tools

Given question of "what are my students doing?" I would want to track a Person's use of LMS features as well as LTI tools. I would expect Event.federatedSession to be consistent for all those events. Event.session then could be used to easily correlate sub-sessions, like use of specific tool.

I think an array of sessionIds is a poor option compared to enforcing federatedSession to be a reliable correlationId for all student interaction. Of course that would mean LTI tools would have to recieve federatedSessionId from the TC and use it when sending events.

Current description

If the Event occurs within the context of an LTI tool launch, the actor's tool consumer LtiSession MAY be referenced. The federatedSession value MUST be expressed either as an object or coerced to a string corresponding to the federatedSession's IRI.

Previous Guidance that didn't make it into the spec https://www.imsglobal.org/forum/la-discussion/112426

The federatedSessionId attribute is not exclusive to LTI launches... so ,it can be included even in the non-federated use cases at the discretion of the system that is using the Caliper Sensor. This can be used to extract records that are part of a single logical "session".

[mashbourne]

What about moving Event.federatedSession into Event.session.federatedSession as a recommended property? @arwhyte @ViktorHaag

Example (including example of a MHE federatedSession we have been sending in events)

{
  "@context": "http://purl.imsglobal.org/ctx/caliper/v1p1",
  "id": "https://example.edu/sessions/1f6442a482de72ea6ad134943812bff564a76259",
  "type": "Session",
  "startedAtTime": "2017-09-15T10:00:00.000Z",
  "federatedSession": {
    "id": "https://connect2-api.mheducation.com/xxx123",
    "type": "LtiSession",
    "launchParameters": {
      "roles": [
        "Administrator"
      ],
      "context_id": "5003200008469",
      "context_title": "Standards Performance Data0628 11:16:09",
      "resource_link_id": "5003200008469",
      "launch_presentation_locale": "en-US",
      "custom_classid": "123456",
      "custom_schoolid": "12345",
      "custom_districtid": "1234",
      "lis_person_sourcedid": "",
      "user_id": "1000030001234782",
      "tool_consumer_instance_guid": "https://connect2-api.mheducation.com",
      "reportId": "topics-performance-report",
      "derivedRole": "schoolAdmin",
      "loggedIn": true,
      "isProduction": true,
      "accountType": "K12"
    }
  }
}

[mashbourne]

A Caliper Session represents a web application user session.

Property	Type	Description	Conformance
Session.id	IRI	local or logical session identifier	Required
Session.federatedSession	IRI/Session	The federated or master session SHOULD be specified. Any system acting as a "portal" allowing students to launch into other applications or tools can provide a federatedSession as part of the launch. This enables analysis of student interactions across separate applications at a session level, without expensive time-windowed sessionization of events.	Recommended
etc	--	--	--

Example Flow

Learning Interaction	Event.session	Event.session.federatedSession
Student logs in	https://example.edu/sessions/1	https://example.edu/sessions/1
Student navigates to course	https://example.edu/sessions/1	https://example.edu/sessions/1
Student opens assigned reading	https://example.edu/sessions/d13494	https://example.edu/sessions/1
Student reads	https://example.edu/sessions/d13494	https://example.edu/sessions/1
Student reads	https://example.edu/sessions/d13494	https://example.edu/sessions/1
Student navigates back to course	https://example.edu/sessions/1	https://example.edu/sessions/1
Student launch LTI tool	https://example.edu/sessions/d13494	https://example.edu/sessions/1
Student does something in LTI tool	https://example.edu/sessions/d13494	https://example.edu/sessions/1
Student logs out of main system
Student logs in	https://example.edu/sessions/2	https://example.edu/sessions/2

[mashbourne]

otherwise could flip this and specify session should be federatedSession if exists, and have a localSession or similar property.

Having them both as top level without recognizing there is a hierarchy involved is asking for issues and inconsistent implementations

[spvickers]

When it comes to an LTI Tool Provider sending events to the event store provided by the LTI Tool Consumer, what is/are the use case(s) for it sending its own session information in addition to the session ID provided by the LTI Tool Consumer? Would it not be better for all events relating to a single session to have session entities which are as similar as possible? This does not preclude an LTI Tool Provider using its own session data when sending events to its own event store; it is just not clear to me what value the LTI Tool Provider's session data is to an LTI Tool Consumer.

[mashbourne]

Would it not be better for all events relating to a single session to have session entities which are as similar as possible?

Yes I would push for federatedSession always being populated when one exists

Having the provider session info just makes it easy to segment that part of the student learning experience. Same could be done if edApp was being set to the Tool Provider name, but that is also optional

[spvickers]

You can also identify the provider events from the sensor ID?

[ViktorHaag]

@spvickers -- One could, but I think we'd need to be stricter about our requirements of the Sensor ID. As it stands it's just "unique" (not "globally unique") and only "should" be an IRI. (I'd be totally OK with stricter requirements on sensor ID.)

One possible challenge here is that (for scaling reasons) it might be possible that a host of Sensor IDs from the same vendor would all be bound up in reporting user activity across a single session... or even a small number (for example a sensor for individual components or services that all handle part of the user's logical interaction session -- one from a video player, one from a content renderer, one from an assessment tool, etc,etc, etc).

[ViktorHaag]

@spvickers The primary use case for "Tool-local session info" as far as I could see would be when the user follows an interaction "within" the context of a single launch (i.e. course materials bound to a particular course) to move over to materials associated with another context (another course). I don't know how important/valuable this would be... also, it's questionable whether the sensor should be using the same API key to send events when they wander "out of the original LTI launch's scope", but I'm not sure either how the endpoint can really be in a position to prevent them (other than by token expiry)...

[spvickers]

@ViktorHaag when a user moves to another context, surely the group entity would change, and not necessarily the session?

[ViktorHaag]

@mashbourne -- I'm not sure I'm comfortable putting federatedSession inside a local session, because that seems like a binding that's artificial. To me, the TP's decision is simple:

• If I get activated from a TC launch and I get a session passed in that launch, that MUST ALWAYS go in Event.federatedSession

• Also, if I track some local session on my side (i.e the LTI message results in SSO-like behaviour), then I might want to put my session data in Event.session

[arwhyte]

@mashbourne - I like your proposal to add Session.federatedSession<Session> as a property of Session and deprecate Event.federatedSession with a preference for Event.session<Session> to refer to the current or local Session as you outline rather than the reverse.

I assume in a chained LTI launch scenario the session info would be recorded as follows:

Learning Interaction	Event.session	Event.session.federatedSession
Student Reads	https://example.edu/sessions/d13494	https://example.edu/sessions/1
Student launches Quiz while in reader	https://example.edu/sessions/q12345	https://example.edu/sessions/d13494
Student submits Quiz while in reader	https://example.edu/sessions/q12345	https://example.edu/sessions/d13494
Student navigates back to reader	https://example.edu/sessions/d13494	https://example.edu/sessions/1

@spvickers - the use cases as I see them:

1. Provide an opportunity to link each Event generated to a current / local Session (i.e., Event.session) assuming such an association can be established in order to permit session-based analysis of user interactions. For an LTI context, whether or not an Event producer is a Tool Consumer or Tool Producer is immaterial, if I can link a user action to the current or local session I want to be able to do that.
2. Allow for event data to be grouped or correlated for analysis to a "federated" session that represents the initial session established by a system acting as a portal, aggregator or orchestrator of services that, if accessed by a user, may generate their own local session info.

For implementors, no.1 above is easiest to comprehend and implement, i.e., I instrument an app, generate events, and have the option of including the current / local user session info when creating each event, if such info exists.

No. 2 requires thinking about relationships between sessions or session hierarchies which is trickier to comprehend. @mashbourne's proposal simplifies comprehension by rendering more explicit the relationship between the current / local session and our notion of a "federated" session (whenever the latter may exist).

[arwhyte]

@ViktorHaag -- there is currently no requirement in the Caliper spec that requires specifying Event.federatedSession.

If I get activated from a TC launch and I get a session passed in that launch, that MUST ALWAYS go in Event.federatedSession

[ViktorHaag]

@spvickers Hmmmm... possibly. This to me is yet another indication that we haven't thoroughly thought out federated session because I can see that "it depends" based on how the Tool Consumer scopes the notion of the session it passes on.

I can see that a TC might want to scope a session to:

• The actual TC user session, across the user's total activity within the TC (I'm not sure I'd want to use the same ID, but I might want a 1:1 binding between the two at this level)

• All launches for that user within a single course context, allowing for tight segregation course over course over course (I might want to do this to more conveniently support, for example, users with varying roles across the TC, course over course (ie learner in one, instructor in one, assistant in one, parent in one, etc, etc)

• All launches for a user from a single LTI launch/resource-link/TProxy, allowing for tight segregation from launch to launch (I might want to do this to allow for strong segregation across tools or across varying content paths, and then do the joins to a "single session" in the data because we have knowledge about the TC's user session and all the related TP-launch sessions)

[ViktorHaag]

@arwhyte I understand: this is tricky I think -- we can't make it mandatory because Sensors might not have a federated session to refer to... but rather like "if I as a TC send you a Caliper Profile Service, we expect that if you support Caliper you will use it"... I suppose that's SHOULD, but really, I feel that's like SHOULD++. 8/

[ViktorHaag]

I'm not a fan of binding these sessions together. I'd prefer to have Event.Session simply support an array of Sessions, rather than composing on inside another.

[ViktorHaag]

I'm worried to start thinking of chained LTI sessions. We explicitly haven't considered that or talked about that workflow. I'd prefer to ensure that we can solidly deliver the simple LTI workflow (which we seem to have concerns about now) rather than expand to talking about a wider array of workflows.

OTOH, if we insist that we must consider more complicated workflows, then I think we're probably safest to punt on LTI entirely for v1.1 (because of timeliness to deliver) and I'm not sure that's going to make people happy...

[arwhyte]

@ViktorHaag -- I reference LTI chaining as an over the horizon issue that nevertheless might play on our thinking. No insistence on my part, just thinking out loud.

[ViktorHaag]

It's certainly something we're going to have to confront at some point.