...
- We need to go through the mock-up code
- make sure the components used are compatible with our IPR regime for distribution
- insert into each file (HTML, JS, etc) the applicable copyright notice and reference to the license.
- Move the mock-up code into a subversion (or similar) repository so we can effectively start tracking version
AI: PAUL: To explore doing the above.
...
- ulx://path-to-RP-metadata-JSON-for-HTTP
- ulxs//path-to-RP-metadata-JSON-for-HTTPS
Paul presented the above and how it is a more universal solution than <object> tags and mime types, etc. Specifically, it works with browsers that don't support some kinds of extensibility (e.g. Mobile Safari, Android/Webkit, etc.)
Scott: I foresee political problems getting agreement on the scheme name (ulx) above.
Paul: To implement the above approach, the RP needs to adapt such that it only shows the above link if there is an active client capability for handling it. This is done by looking the "capabilities" listed in the request header. Actually this brings up another problem. We detect the header and look a the "capabilities": we have no agreement on how to indicate the capabilities of the active client. Hmmm... ULX scope increases yet again.
Scott: This scheme approach is an old trick. But since the W3C is against folks creating new schemes, folks are gun shy about suggesting this. The right way to do this is mime types, but as has been d
4) Finnish selector use case
...
Keith created the above page.
Paul: If the grouping is optional then the UX if grouping isn't needed would appear as it currently does in our prototype.
Bob: Yes, but is this desirable? Does our notion of universality include this kind of optionality?
Paul: I see what you're saying. You're saying that more optionality be definition leads to increased inconsistency.
Bob: Yes. I'm asking if grouping or non-grouping a legitimate choice.
Scott: there's currently an un-met requirement in the current mockup (i.e. priority IdPs vs. non-priority). So one could capture this notion in something more general that would handle the grouping Keith shows here. The RP could attach its own tags --its own criteria for how the grouping is done.
Keith: What do folks think about priority/ordering?
Scott: I wasn't thinking about using keywords for that. So we don't have a proposal on the table for that. Keywords seems awkward.
Paul: AI: to discuss this with UX person. Is less more. Is this desirable.
Scott: You can't stop people. So the real question is does having some consistency have a benefit vs. a custom UI.
Paul: Keith clearly you believe that having ULX be extended to have support for grouping and priority would be a benefit.
Keith: Yes and these are just two examples of many in Finland.
Paul: I know Scott disagrees, but I like the fact that the username/password there.
Keith: In the second example (example 2) it is a second click away.
Bob: Even though we all agree with approach. 99% of your current users will find this an extra step of course. Just looking around having username/password having to be on a separate page is pretty common.
Adjourn.
We did not discuss the following:
5) Unresolved issues from previous meeting
...