[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: OSLC CORE TC minutes Nov 29, 2018
Martin Sarabura: Martin will scribe https://www.oasis-open.org/apps/org/workgroup/oslc-core/email/archives/201811/msg00012.html Martin Sarabura: Minutes accepted Martin Sarabura: OAuth permissions? Martin Sarabura: No need for special permissions since comments are public Martin Sarabura: Martin to send appropriate github access to Jim Martin Sarabura: Do need to check in repo - which will be protected Martin Sarabura: No, repo is public - have to pay for private - so still need token but no need for oauth permissions to be granted Martin Sarabura: Query spec published Jim Amsden: Motion: I move that the OSLC Domains TC approve submitting OSLC Query Capability Specification Version 3.0 and all associated artifacts packaged together in https://www.oasis-open.org/apps/org/workgroup/oslc-core/download.php/64343/oslc-query-csprd01.zip as a Committee Specification Draft, designate the HTML version of the document as authoritative, and for 30 days public review. Martin Sarabura: (Back to previous topic) Do all permissions since it's just a test repo anyway Martin Sarabura: Martin 2nd the motion Martin Sarabura: Change log in the repository Martin Sarabura: Date extended out a couple of weeks to allow for voting to complete Martin Sarabura: 2019 needs to be 2018 Martin Sarabura: doc links needed to be fixed to conform to oasis Martin Sarabura: renumbered previous history - revision history of the published oasis document, not the actual history Martin Sarabura: HTML verification on the document and links Martin Sarabura: Should not be any broken links other than links to published docs which is unknown until they are punished Martin Sarabura: OASIS will verify the mechanical stuff - otherwise content is unchanged. Jim Amsden: +1 David Honey (Persistent/IBM): +1 Martin Sarabura: +1 Andrew Berezovskyi (KTH): +1 Martin Sarabura: Accepted Martin Sarabura: Martin to publish these meeting notes asap so Jim can reference them Martin Sarabura: ie., send minutes to core TC list Martin Sarabura: Naming conventions and relative links Martin Sarabura: OASIS will not change naming guidelines Martin Sarabura: Thus SCM repository will not align with filenames on the published site Martin Sarabura: Jim has 3 options: Martin Sarabura: OASIS please reconsider? (hat in hand) Martin Sarabura: Implement the naming conventions inside of respec and have respec adjust any relative references that it finds Martin Sarabura: Redirect to preserve the original file names Martin Sarabura: Jim expects they will use the third approach Martin Sarabura: David: Desirable if we can extend results to local copy Martin Sarabura: Jim: Respec would be responsible for translating only when generating html Martin Sarabura: Document would have proper scm file names in it Martin Sarabura: Tricky is to find all the hrefs Martin Sarabura: Jim hoping they will adopt either 1 or 3, with 1 being unlikely Martin Sarabura: David: Must be other similar projects in OASIS? Martin Sarabura: Jim: We have quite a few documents in our spec Martin Sarabura: Andrew: Discovery of discovery? Martin Sarabura: Andrew to follow up with Martin Pain Martin Sarabura: Andrew found more interest in standardizing discovery that we already have Martin Sarabura: Root services common practice - feedback that this was most desirable Martin Sarabura: Still need the URL - no standard name for it Martin Sarabura: Even if you knew the relative URL still need host and port Martin Sarabura: and protocole Martin Sarabura: Ya gotta know somethin Andrew Berezovskyi (KTH): https://docs.google.com/document/d/1qczVGQXNdv8wXf-hilh8cgcTVOOWvmA9TWVogW5qGKU/edit# Martin Sarabura: Scenario 5: OSLC admin does not have sys admin privileges Martin Sarabura: Jazz uses oauth 0.1.a tokens Jim Amsden: http://oslc.github.io/developing-oslc-applications/iotp_adaptor/rootservices.html Andrew Berezovskyi (KTH): https://jazz.net/wiki/bin/view/Main/RootServicesSpec#OAuth_Service_Provider_Propertie Andrew Berezovskyi (KTH): The priority is to capture the discovery mechanisms necessary to be implemented by the vendors to allow the tools to be able to connect to the OSLC-based tools widely used today. This involves reading the spec on Jazz.net linked above and reverse-engineering the responses of the tools in the wild. Martin Sarabura: Jim: Are we trying to standardize the Jazz approach? Martin Sarabura: If we want 2 servers to be able to interact Andrew Berezovskyi (KTH): added the scenario no. 6 to the Google Doc Martin Sarabura: Isn't the purpose to enable client-based integrations? Martin Sarabura: Jim: Still need to store the URL on a server Martin Sarabura: Even a server is a client to another server Martin Sarabura: How that's done varies considerably Martin Sarabura: OpenID connect is still just a recommendation Martin Sarabura: Standardizing how to discover authentication mechanisms seems like a whole different spec Martin Sarabura: Has been an ongoing issue Martin Sarabura: Biggest stumbling block to integration has always been authentication Martin Sarabura: Running in a browser use fetch - in a node application have to do it manually Martin Sarabura: Bottom line: There is a need, but it's a big problem - need extra people to do it! Martin Sarabura: There are docs on jazz.net describing different auth approaches and how to use them Martin Sarabura: Open ID connect tries to standardize it, but it's just one of many approaches Martin Sarabura: Problem that customers are having is what to do with non-Jazz tools - Martin Sarabura: We're well positioned to standardize discovery of the critical items, and Andrew could run with it Martin Sarabura: It would be an interesting discussion re open projects Martin Sarabura: Andrew will summarize over email Martin Sarabura: Martin to submit tab request Martin Sarabura: Meeting adjourned |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]