Background
- I have implemented a terms & conditions acceptance workflow that uses a date-based comparison (a hard-coded
latest T&C date parameter against a termsOfUseConsentDateTime claim.
- This uses a "GetCurrentDateTime" transformation to output a claim,
currentTime, that is used as an input claim and stored as the date the user accepts the claim.
The claim workflow was doing what I expected in sign in and registration scenarios, with the appropriate claim being set with the consent date and time. This is using a contentdefinition called api.selfservice.termsandconditions that I defined, that points to a specific HTML page.
Goal
I wanted to add some custom JS to the page to enforce the scrolling of the T&C content, etc.
What I did
Made the following updates, per directions in the docs
| Previous value |
Changed To |
New Value |
| urn:com:microsoft:aad:b2c:elements:globalexception:1.1.0 |
--> |
urn:com:microsoft:aad:b2c:elements:contract:globalexception:1.2.0 |
| urn:com:microsoft:aad:b2c:elements:idpselection:1.0.0 |
--> |
urn:com:microsoft:aad:b2c:elements:contract:providerselection:1.2.0 |
| urn:com:microsoft:aad:b2c:elements:unifiedssp:1.0.0 |
--> |
urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:1.2.0 |
| urn:com:microsoft:aad:b2c:elements:selfasserted:1.1.0 |
--> |
urn:com:microsoft:aad:b2c:elements:contract:selfasserted:1.2.0 |
Problem
After changing these contact values, it appears my claim value is no longer captured in the workflow. As a result, the "current time" ends up being null and the time of acceptance it's based on ends up getting a default value (seen coming back via jwt.io).
I have verified using git bisect that the problem appears to come into play as soon as I change these data URIs.
Question / Ask
Can someone help me understand the impact of changing these data URIs and why they might be the difference in my claims not operating as I'd expect them to?
Thanks!